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SUMMARY 

PROBLEM 

To  develop  and  demonstrate  an  algorithm  (scheme)  that  will 
identify,  from  among  the  myriad  of  possible  plans,  the  most  cost- 
effective  plan  for  the  phase-in  and  phase-out  of  vehicle  systems  — 
a  methodology  for  optimal  fleet  planning  over  time. 

DISCUSSION 

This  report  describes  an  optimization  methodology  that  accepts 
as  input  the  numbers  and  costs  associated  with  alternative  mixes  of 
vehicles  (machines),  such  that  each  mix  can  perform  a  series  of  tasks 
with  equal  effectiveness,  and  provides  as  output  the  numbers  and  cost 
of  the  "least-cost-mix"  that  will  meet  a  prescribed  level  of  effective¬ 
ness. 

The  concept  of  the  new  algorithm  is  easily  seen  by  comparison  • 
with  traditional  methods  of  solutions  as  implied  by  the  following 
sketch: 
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In  the  traditional  methods,  a  future  time  (planning)  period  it 
selected,  at  the  beginning  of  which  all  of  the  considered  systems  could 
be  made  available  if  desired,  and  certain  approximations  made  regarding 
the  inherited  assets  (existing  systems)  and  their  status.  The  optimiza¬ 
tion  is  then  conducted  on  a  one-time  (snap-shot)  basis  for  the  selected 
period  of  time  (typically  10-12  years)  as  implied  by  the  dashed  lines 
in  the  shaded  portion  of  the  sketch.  No  information  is  made  available, 
or  is  provided,  regarding  the  interim  period  between  the  present  time 
and  the  start  of  the  planning  period.  In  addition,  it  is  typical  for 
all  data  (both  input  and  output)  to  be  considered  to  be  averaged  over 
the  planning  period. 

In  the  new  algorithm,  the  optimization  is  conducted  "dynamically" 
over  an  extended  period  of  time  (say  15-25  years)  beginning  with  the 
present  status  of  the  existing  systems  and  concluding  at  the  end  of 
the  planning  period.  This  permits  full  and  explicit  consideration  of 
the  inherited  assets  and  their  aging  characteristics  as  wo''l  as  the 
initial  operational  capability  (IOC)  dates  of  the  proposed  new  systems 
and  their  growth  characteristics.  The  optimization  is  conducted  over 
the  complete  (extended)  period,  phasing  out  old  systems  (e.g.,  system  A) 
as  obsolescence  occurs,  and  phasing  in  new  systems  (e.g.,  systems  B  &  C) 
as  they  become  available.  The  response  to  changing  military  requirements 
is  controlled  by  structuring  the  complete  period  in  terms  of  smaller  and 
smaller  subperiods  so  as  to  obtain  (almost)  a  continuous  adjustment  of 
the  status  of  all  systems,  ss  implied  by  the  solid  lines  in  the  sketch. 

It  is  noted  with  emphasis  that  the  user  must  specify  the  input  data 
array  which  details  the  task  (mission  group)  requirements  for  each  sub- 
period  within  the  planning  horizon. 
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In  specific  terras,  the  methodology: 

.  Provides  a  global  (optimal)  solution  over  the  entire  time 
period  of  interest, 

.  Accounts  for,  and  makes  optimal  use  of,  inherited  assets, 

.  Determines  when  and  if  to  phase-in  new  systems, 

.  Determines  if  and  when  to  phase-out  existing  systems, 

.  Can  account  for  step-discontinuities  in  cost,  such  as  develop¬ 
ment  expenses, 

.  Can  account  for  decreased  procurement  costs  as  the  quantity 
of  systems  increases  (learning  curve  effect), 

.  Allows  input  of  increased  operating  costs,  if  appropriate, 
as  the  age  of  the  vehicles  increase, 

.  Allows  input  of  budgetary  constraints,  by  category  if  appro¬ 
priate,  and 

.  Accounts  for  "retained  value"  of  the  systems  at  the  end  of 
the  time  period. 

The  mathematical  statement  of  the  programming  problem  is  of  the 

following  form:  Find  a  vector  x  «  (x^»  . ..,  xr)  that  will 

n 

minimize  <t>  (x)  -  T  0.  (x. ) 

i«l  1  x 

subject  tox6G,  0<x<L 

where 

<t  «  the  total  cost, 

x  ■  a  vector  representing  the  nuiriber  of  vehicles  of  each  type, 

0  -  the  constraint  set, 

L  ■  the  vector  of  upper  bounds, 

and  the  subscript  i,  i  ■  1,  2,  . . .  n,  denotes  the  vehicle  type.  There 
are  two  restrictions  on  the  form  of  the  cost  function.  First,  the 
function  must  be  "separable"  which  means  that  each  type  of  vehicle 

S-3 

dCSfc 


can  be  coated  independently.  The  second  restriction  is  that  the  cwsula- 
tive  cost  curve  for  an  Increasing  quantity  of  each  type  of  vehicle  must 
be  concave.  This  means  that  a  straight  line  connecting  any  two  points 
on  the  curve  lies  on  or  below  the  cu'  ve  at  all  intermediate  points. 

These  requirements  are  generally  satisfied  in  cost  minimisation  problems 
—  that  is,  those  problems  where  it  is  appropriate  to  minimise  cost  for 
a  specified  level  of  effectiveness.  In  addition,  there  are  three  restric¬ 
tions  on  the  constraint  set:  (l)  all  of  the  constraints  must  be  linear, 

(2)  none  of  the  constraints  can  be  strict  inequalities,  and  (3)  the 
number  of  vehicles  of  each  type  must  be  bounded  from  above  and  below. 

The  general  procedure  of  the  algorithm  is  as  follows:  The  set 
of  all  possible  solutions  is  successive^  broken  into  smaller  and  smaller 
subsets.  For  each  such  subset  of  solutions,  a  lower  bound  on  the  cost 
of  the  best  solution  ir.  the  subset  is  calculated.  At  each  iteration  of 
the  algorithm  the  subset  with  the  lowest  lower  bound  is  broken  into  two 
smaller  subsets.  Eventually,  a  subset  consisting  of  exactly  one  solu¬ 
tion  is  found  and  it  has  an  actual  cost  that  is  less  than  or  equal  to 
the  lower  bound  for  all  other  subsets.  This  is  the  least  cost  solution. 

The  lower  bounds  are  found  by  solving  the  problem  with  linear  cost  func¬ 
tions  Instead  of  the  actual  concave  cost  functions. 

Once  the  least-cost  solut'n  has  been  obtained,  the  sensitivity 
of  this  "optimal  plan"  to  possible  errora  in  the  user  specification  of 
the  input  requirements  can  be  determined.  In  other  words,  the  consequences 
of  the  uncertainty  of  the  input  data  can  be  explored  by  manipulation 
(calculations)  within  the  computer  program  itself.  Many  of  these  sensi¬ 
tivity  results  can  be  displayed  automatically,  as  standard  output  — 
other  results  can  be  efficiently  re-computed  from  the  results  of  the 
optimal  plan. 


Volume  I  of  this  report  provides  a  systematic  development  of  the 
problem  structure,  a  qualitative  description  of  the  solution  procedure, 
and  mathematical  and  operational  descriptions  of  the  algorithm.  Volume 
II  provides  appendices  containing  a  demonstration  problem,  subroutine 
descriptions,  program  flow  charts,  program  listings,  and  error  message 
descriptions.  Those  readers  who  are  interested  In  a  general  (non-mathema- 
tical)  understanding  of  the  methodology  should  confine  themselves  to 
the  Introduction,  Chapters  1  and  2,  and  possibly  Appendix  A.  Those 
who  are  Interested  in  the  mathematical  substance  should  concentrate 
further  on  Chapter  3.  Chapter  k  and  the  remaining  appendices  9re  for 
the  "users"  and  "programmers." 

CONCLUSIONS 

This  algorithm  provides  Army  planners  with  a  comprehensive 
non-linear  methodology  which  can  be  used  for  Minimising  costs  over  long 
planning  periods.  While  the  emphasis  in  this  report  is  on  "fleet 
planning"  exercises,  the  methodology  is  generally  applicable  to  problem 
involving  "machines"  of  any  type  (e.g.,  computers,  motor/generator  sets, 
radio  sets,  etc.). 

A  principal  strength  of  the  algorithm  is  the  ease  with  which 
sensitivity  analyses  can  be  conducted  and  the  facility  with  which  input 
data  may  be  changed  to  -eriodically  update  the  planning  process.  The 
structure  of  the  methodology  is  sufficiently  general  to  be  used  in  all 
optimisation  problems  appropriate  to  the  atsumptions  and  conventions. 

The  algorithm  can  accept  large  enough  problems,  and  runs  with  sufficient 
rapidity  to  be  used  as  a  standard  research  tool. 


INTRODUCTION 


The  set  of  criteria  which  one  uses  to  select  one  eapital  invest¬ 
ment  proposal  over  another  may  vary,  but  there  is  no  substitute  for 
being  able  to  view  interactive  business  operations  In  their  entirety; 
that  is,  it  is  certainly  desirable  to  see  the  influence  of  an  aoti.on, 
taken  at  a  given  time  and  place,  on  the  overall  costs  (or  effeotlvsnes i) 
of  a  major  procurement  program.  This  report  is  the  result  of  such  an 
effort  in  that  most  quantifiable  factors  which  affect,  or  are  affected 
by,  a  single  capital  equipment  investment  are  aggregated  and  viewed  in 
their  interactive  state.  In  this  way,  the  program  manager  can  test  and 
probe  a  model  of  his  operation  to  see  the  influence  of  each  oapltal 
Investment  proposal. 

The  manager  today  is  very  often  faced  with  decisions  regarding  the 
purchase  of  capital  equipment  within  a  very  complex  problem  environment. 
These  questions  may  be  familiar  ones— Should  the  old  vehicles  be  re¬ 
placed?  . . .When? — But  the  new  models  won't  be  available  until  late  in 
*73;  should  we  order  immediately? — That  looks  good  now,  but  what  about 
costs  over  the  long  term?  These  questions  are  oertalnly  not  new  to  the 
program  manager— he  has  been  "solving"  them  for  years  using  experienced 
Judgment  and  various  rules -of- thumb;  but,  it  is  no  secret  that  these 
methods  are  not  altogether  satisfactory.  In  fact,  such  methods  are  weak 
because  they  only  begin  to  solve  the  problem. .. such  methods  are  super¬ 
ficial  in  the  sense  that  they  appear  to  account  for  the  primary  factors, 
but  fail  because  they  do  not  consider  the  important  interactions.  The 
methodology  reported  on  here  utilizes  an  interactive  model  wherein 
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an  account  is  taken  of  variations  in  the  problem  environment  over 
time:  i.e.,  the  "dynamics"  of  the  long  term  plan  are  Inherent  in  the 
model. 

In  most  cost-effectiveness  analyses  it  is  usual  that  one  seeks  to 
finj  an  optimal  solution  — -  i.e.,  a  mini  urn  cost  or  a  maximum  effective¬ 
ness  solution,  subject  to  oertain  problem  constraints.  The  following 
describes  an  optimisation  methodology  which  accepts  as  input  the  numbers 
and  oosts  associated  with  alternative  mixes  of  vehicles  (machines) ,  such 
that  each  mix  can  perform  a  series  of  tasks  with  4oal  effectiveness, 
and  provides  as  output  the  numbers, schedule, and  cost  of  the  "least-cost- 
mix"  that  will  meet  the  prescribed  level  of  effectiveness.  The  problem 
that  we  oonsldaj  here  is  dynamic,  hence,  we  call  this  a  "phasing" 
problem  since  its  solution  specifies  the  orderly  and  efficient  phase-in 
and  phase-out  of  a  fleet  of  vehicles  or  machines.  In  this  context, 
Hetrick1  has  noted  that:  "Some  managements  pay  only  lip  service  to  the 
idea  that  decisions  should  be  made  to  the  best  advantage  of  the  total 
enterprise  and  for  the  long  term.  All  too  frequently,  short  term 
decisions  are  made  that  are  crippling  in  the  long  term."  It  may  be 
convenient  to  think  of  this  problem  as  a  multi-stage  decision  process 
where  the  interdependence  between  stages  (sub-periods)  is  due  to  the 

inheritance  of  a  fleet  of  machines  from  a  previous  sub-period. 

> 

The  algorithm  that  is  used  to  obtain  the  least-cost  solution 

is  of  the  "branch-and-bound"  type  and  solves  a  sequence  of  sub-problems, 

2 

each  of  which  evolves  into  a  linear  program. 

In  Chapter  1  of  Volume  I  we  structure  the  problem  by  systematically 
developing  the  array  of  alternatives  to  satisfy  prescribed  requirements. 
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Here  the  requirements  are  aggregated  into  independent  groups  of  missions 
in  building-block  fashion  and  a  concise  problem  statement  is  developed. 
Chapter  2  provides  a  qualitative  description  of  the  solution  procedure 
in  order  to  demonstrate  its  logic  and  intuitive  appeal.  A  mathematical 
description  of  the  algorithm  is  given  in  Chapter  3»  here  the  problem 
statement  is  transformed  into  the  general  non-linear  programming  form, 
and  the  solution  procedure  explained  with  some  rigor.  Chapter  4  is 
an  operational  description  that  translates  the  algorithm  into  the 
language  used  in  the  computer  code. 

Volume  II  contains  a  series  of  appendices  (A  through  E)  designed 
for  the  user  and  programmer.  Included  are  a  detailed  description  of  a 
sample  problem,  subroutine  descriptions,  program  flowchart! ,  a  program 
listing,  and  an  explanation  of  all  program  error  messages- 
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PROBIZM  8TRUCTUKI 

Let  ua  uiim  that  there  exist  or  that  one  ean  generate,  llsta  of 
alternative  combinations  of  vehlolea,  auoh  that  eaoh  alternative  satisfies 
the  requirements  of  a  particular  mission  group.*  For  example,  a  typical 
set  of  these  alternatives  might  look  like  that  in  Fig.  1. 


^"^^**---^jrehicle  Type 
Alternative  #* 

Vehicle 

#1 

Vehicle 

#2 

Vehicle 

#3 

Vehicle 

#4 

Vehicle 

#5 

1 

46 

15 

63 

104 

138 

2 

0 

15 

82 

104 

138 

3 

46 

0 

70 

104 

138 

4 

0 

0 

90 

104 

138 

5 

46 

15 

0 

167 

138 

6 

0 

15 

0 

187 

138 

7 

46 

0 

0 

176 

138 

8 

0 

0 

0 

196 

138 

9 

46 

15 

63 

0 

265 

10 

0 

15 

82 

0 

265 

11 

46 

0 

70 

0 

26^ 

!  12 

0 

0 

90 

0 

265 

13 

46 

15 

0 

0 

313 

14 

0 

15 

0 

0 

328 

15 

46 

0 

0 

0 

315 

16 

0 

0 

0 

0 

332 

Fig.  1-1.  A  Typical  List  of  Alternative  Vehicle  Arrays 
Which  Could  Service  a  Mission  Croup 


Ideally,  eaoh  of  the  alternatives  (rows)  on  a  given  list  must  satisfy  the 
requirements  of  the  corresponding  mission  group  with  equal  effectiveness. 


*  "Mission  group"  is  meant  to  bo  synonymous  with  "series  of  tasks"  or 
"collection  of  Jobs"}  the  important,  point  here  is  that  vehicles  (maehines) 
may  be  "pooled"  to  aooompllsh  the  objeotlve(a) ,  l.e.,  eaoh  "job"  need  not 
be  performed  by  physioally  different  vehicles. 


Th*  Job  of  tb«  optimitation  methodology  is  to  ohooa*  on*  alternative  fro* 
eaoh  Hat  (mlaalon  group)  ao  that  the  total  *lx  la  leaat  ooatly.  for  a 
alngle  mlaalon  group  the  taak  here  la  a  almple  one,  1.*.,  one  need  merely 
evaluate  the  ooat  of  eaoh  and  every  alternative,  and  then  aeleet  that  one 
having  the  leaat  ooat,  Aa  long  aa  thla  Hat  la  not  unreaaonably  long  (and 
a  liat  of  one  million  alternatlvea  lje  no£  unreaaonably  long),  then  the  taak 
la  not  prohibitive.  When  there  exlata  two  or  more  Independent*  mlaalon 
group a ,  then  the  number  of  feaaible  oomblnatlona  grea  up  rather  quickly. 
Conalder,  for  example,  a  problem  Involving  eight  independent  miaaion  groupa 
eaoh  of  which  oontalna  twenty  alternativea,  aa  ahown  in  Fig.  1-2.  Bine*  the 
ooat  relatlonahipa  are  in  general  non-linear  (fixed  Md)  chargee  and  learning 
curve*) ,  the  leaat-ooat-mix  will  not  be  the  almple  combination  of  the  leaat- 
coat  alternative  for  eaoh  miaaion  group.  The  optlmlaatlon  problem  here  la 
to  aeleet  one  alternative  from  eaoh  of  the  eight  mlaalon  groupa  aueh  that 
thla  combination  (mix)  of  alternativea  la  th*  leaat-ooat-mix.  Again,  w* 
could  attempt  to  explicitly,  enumerate  eaoh  and  every  combination,  but  a 

g 

little  thought  will  reveal  that  there  exlat  20  poaalbl*  oomblnatlona. 

If  each  combination  oould  be  evaluated  in  one-hundredth  of  a  aeoond  on  a 
modern  computing  maohlne,  th*  total  aet  of  evaluation*  would  require  more 
than  50,000  houra  of  computing  time.  It  ia  thla  problem  (and  only  thla 
problem)  which  preclude*  explioit  enumeration  of  all  poaalbl*  aolutlona  and 
requlrea  the  use  of  a  more  aophlatioated  optlmlaatlon  teohniqu*.  furthermore, 
we  have  not  yet  conaldered  the  additional  oomplexity  introduced  by  the 
element  of  time,  l.e.,  the  problem  ia  not  yet  dynamio.  The  requirement* 
repreaented  by  the  eight  Independent  miaaion  groupa  deaorlbed  above  may  be 

*  Mia r Ion  groupa  are  independent  if  th*  vebiolea  uaed  to  aatiafy  on* 
mlaalon  group  are  not  (cannot  be)  uaed  to  aatiafy  th*  other. 
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thought  of  u  originating  at  eight  separate  geographical  locations  but 
occurring  at  essentially  the  mm  time  —  it  la  in  this  sense  that  the 
mission  groups  art  independent.  Actually  we  would  Ilka  to  consider  the 
acre  general  problem  of  satisfying  an  array  of  requirements  in  a  sequence 
of  time  periods  coonencing  now  and  ending  at  sometime  in  the  futurs.  We 
oan  accommodate  this  additional  time  dimension  in  the  problem  by  developing 
arrays  of  mission  groups  like  those  of  Fig.  1-2  for  eaoh  sub-period  within 
the  total  time  period  of  oonoern.  To  oontinue  with  cur  example,  we  could 
develop  a  tableau  like  that  of  Fig.  1-3  whioh  displays  eight  mission 
groups  for  eaoh  of  1?  yearly  sub-periods  from  1971  thru  1985.  This  is  not 
to  imply  that  there  must  exist  any  regularity  or  uniformity  to  the  number 
of  mission  groups  per  sub-period,  or  alternatives  per  misalor  ,  ~oup,  etc. 

—  there  need  only  exist  a  finite  number  of  equally  effect i\ <i  alternatives 
for  eaoh  Independent  mission  group  within  eaoh  sub-period.  Of  course,  the 
duration  of  the  sub-period( s)  is  a  measure  of  the  "resolution"  of  the 
problem  and  should  be  selected  ty  the  model  manipulator  (user)  from  the 
state  of  knowledge  whioh  exists  of  the  predicted  requirements  for  that 
sub-period. 

Finally,  we  complete  the  description  of  the  problem  structure 

by  noting  that  there  can  oxist  at  the  beginning  of  the  first  sub-period 

an  Inherited  fleet  of  machines.  This  Inherited  fleet  is  characterized 

* 

by  number,  type,  and  vintage  and  may  be  used  to  satisfy  part  or  all  of 
the  requirements  of  subsequent  sub-periods.  It  may  now  be  obvious 
that  the  interdependency  between  sub-periods  derives  from  the  inheritance 
of  machines  from  sub-period  to  sub-period  and  if  that  inheritance 

•The  vintage  or  age  of  each  inherited  machine  will,  in  general, 
Influence  the  operating  cost  and  salvage  value  of  that  machine. 
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were  ignored,  than  the  leaat-coat-aolution  for  the  entire  time  period 
would  be  the  sub  of  the  leaat-ooat-aolutione  for  eeoh  aub-period. 


The  problem  atruoture  ea  defined  in  the  preceding  paragraphe 
providea  the  foundation  for  a  conciae  problem  statement: 

PROBLEM  STATEMENT 

We  aeek  to  aatiafy  the  fixed  and  preecribed  requireawnts  in  each 
and  every  aub-period  with  that  mix  of  nachinee  which  will  minimise  the 
total  overall  coat.  Thia  leaat- coat -mix  oust  obtain  from  the  aeleotion 
of  one  alternative  for  each  miaaion  group  within  each  aUb-period,  in 
conjunction  with  an  optimal  retention  of  inherited  aaaeta. 
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Chapter  2 


A  QUALITATIVE  DESCRIPTION  07  THE  BRANCH- AND- BOUND 
SOLUTION  PROCEDURE 

The  number  of  poaaibi#  (feasible)  solutions  to  a  typical  "multi¬ 
stage  phasing"  problem  la  enormous;  the  example  problem  repreaented  by 

120 

the  tableau  In  Tig. 1-3 baa  more  than  20  poealble  aolutlona!  Clearly, 
some  systematic  aolutlon  procedure  which  by-paaaea  oomplete  enumeration 
of  all  poealble  aolutlona  la  needed. 

We  seek  to  minimise  acme  coat  (objective)  .unction  which,  at  the 
very  leaat,  refloats  the  expense  Involved  In  developing,  purchasing,  and 
operating  a  fleet  of  machines  over  an  extended  time  period.  Furthermore 
this  minimisation  must  be  carried  out  subject  to  certain  requirement, 
production,  and  cost  constraints.  The  specific  details  of  the  oost 
equation  can  be  deferred  for  the  moment,  but  the  general  form  of  the 
function  la  Important  here.  A  typical  vehicle  coat  curve,  plotting 
total  coat  versus  number  of  vehicles  purchased  and  operated  la  shown 


The  co»t  Jump  it  x  ■  0  represents  the  RAD  expenditure, which  oust  occur 
prior  to  the  procurement  of  any  number  of  thla  particular  vehicle.  For 
x  greater  than  0,  the  deviation  from  linearity  derlvee  from  the  "learning" 
advantage  of  a  volume  purchaae.  The  function  repreaented  by  thla  curve 
la  called  a  "concave"  function  and  it  la  thla  oharacteriatic  vhloh  acti¬ 
vate  a  the  braneh-and-bound  aolution  procedure.  A  concave  function  of  a 
tingle  variable  la  one  whoae  graph  la  never  "below"  a  straight  line  Joining 
any  two  pointa  of  that  function.*  That  la,  the  straight  line  value  la 
always  less  than  or  equal  to  the  function  value  and  we  note,  Importantly, 
that  this  straight  line  approximation  will  always  yield  an  "underestimate" 
of  the  concave  coat  function. 

Now,  let  ua  visualize  enclosing  all  20  solutions  of  our  sanqple 
problem  by  the  solid  line  in  Flg.2-2a.  This  box-like  enclosure  contains 
the  entire  set  of  solutions  and  we  will  ultimately  partition  this  set 
into  subsets,  the  partition  being  indicated  by  the  dotted  lines.  A 
second  representation  of  the  partitioning  procedure  la  shewn  by  the 
"branching”  diagram  in  Fig.  2-2b{  nera,  a  tree  of  branches  la  formed  In 
one-to-one  correspondence  with  the  partitioned  aubaets  with  each  node 
corresponding  to  a  dottad  partition  line.  Each  node  on  the  branching 
tree  Identifies  a  linear  progressing  problem.  Initially,  we  obtain  the 
oost  of  one  (any  one)  mix;  this  coat  la  called  the  reference  aolution. 

We  divide  the  total  set  of  solutions  Into  two  subsets,  l.e.,  we  form 
two  branches  (see  diagram).  We  then  calculate  a  lower  bound**  (under¬ 
estimate)  to  the  solutions  In  each  subset  by  solving  the  corresponding 

*  A  more  general  and  more  rigorous  definition  of  n  concave  function 
la  given  in  Chapter  3. 

**  A  lower  bound  in  a  given  subset  is  a  cost  less  than  or  equal  to 
the  coat  of  any  aolution  in  that  subset. 
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linear  programs  and  compare  these  lover  bounds  to  the  cost  of  the 
reference  solution.  There  are  three  cases  to  considers  (l)  both  lower 
bounds  are  less  than  the  cost  of  the  reference  solution,  (2)  one  lower 
bound  is  less  than  the  reference  solution,  (3)  neither  of  the  lower 
bounds  are  less  than  the  cost  of  the  reference  solution.  A  description 
of  the  procedure  to  be  followed  for  case  (2)  will  suffice  for  all  cases. 

If  a  lower  bound  is  greater  or  equal  to  the  reference  solution,  its 
corresponding  subset  cannot  contain  a  better  solution  than  the  reference 
solution  and  this  is  the  basis  for  discarding  this  entire  subset  of 
solutions.  If  a  lower  bound  is  less  than  the  reference  solution,  the 
corresponding  subset  can  contain  the  least-cost- solution;  hence,  this 
subset  is  partitioned  again  and  the  testing  process  repeated.  For  each 
subset  having  a  lower  bound  less  than  the  current  reference  solution,  a 
new  reference  solution  is  calculated  from  this  candidate  subset.  If  this 
new  solution  is  less  than  the  old  reference  solution,  we  replace  the  old 
with  the  new.  This  entire  process  can  be  shown  to  converge  to  the  least- 
cost-  solution  of  the  entire  set  of  solutions.  The  specific  details  aj  to 
how  one  calculates  the  lower  bounds,  partitions  the  subsets,  chooses  the 
branching  rules,  etc.,  is  left  for  Chapter  3.  Nevertheless,  it  should  now 
be  clear  that  the  efficiency  of  this  algorithm  stems  from  the  freedom  to 
legitimately  discard  large  groups  of  possible  solutions  without  ever 
explicitly  evaluating  them  —  only  a  small  fraction  of  the  total  number 
of  solutions  need  be  evaluated. 

Finally,  it  should  be  noted  that  the  branch-and-bound  procedure 

120 

actually  considers  many  more  than  the  20  (or  so)  discrete  possible 
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solutions  to  our  sample  problem.  In  faot,  a  continuum  of  possible 

120 

solutions  is  considered,  comprised  of  the  20  discrete  solutions 
plus  all  convex*  combinations  of  the  discrete  solutions.  In  so  doing, 
it  is  assumed  that  all  such  convex  combinations  represent  equally 
effective  alternative  solutions  to  the  problem. 


*  A  "oonvex"  combination  is  a  linear  combiQ^tion  of  a  speoial  type, 
e.g. ,  a  convex  combination  of  two  vectors  U,  and  U„  is  Cow,  *  |IL]  such 
that  er  *  9  •  1.  A 
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Chapter  3 


MATHEMATICAL  DESCRIPTION  OP  THE  PROBLEM 
AND  ITS  SOLUTION 

The  mathematical  problem  statement  is  of  the  following  form: 

Find  a  vector  x  ■  (x^,  xQ)  which  will 

n 

minimize  I  (x)  ■  E  l-Cx.) 
i-1 

subject  to  x  €  0, 

0  a  x  <L 

We  develop  now  the  specific  and  detailed  structure  of  the  model  beginning 
with  the  constraint  set,  0. 

CONSTRAINT  SET 

In  this  problem  there  are  three  basio  activities  whioh  interact , 
and  associated  with  each  activity  is  a  problem  variable.  The  value  of 
the  problem  variable  indicates  the  level  at  which  the  activity  is  to  be 
conducted.  The  first  aotivity  is  the  disposition  of  the  inherited  assets. 
The  problem  variable  is  Wj^,  which  refers  to  the  number  of  Jthtype 
machines  which  were  purchased  at  the  beginning  of  subperiod  4  and  will 
be  disposed  of  at  the  end  of  subperiod  m.  The  second  activity  is  the 
purchase  and  disposition  of  new  machines,  and  its  variable  is  x^, 
where  the  subscripts  have  the  same  meaning  as  above.  The  third  activity 
is  related  to  the  performance  of  the  mission  requirements.  The  problem 
variable  is  p^j»  the  fraction  of  alternative  k  to  be  used  in  accomplish¬ 
ing  the  1th  mission  group  in  subperiod  4. 
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Materiel  Balance  Constraints 

The  most  basic  constraints  relate  the  interaction  between  activi¬ 
ties.  They  insure  that  the  machines  which  we  have  available  in  any 
subperiod  are  sufficient  to  meet  the  mission  requirements  of  that  sub¬ 
period.  The  machines  available  in  subperiod  i  are  determined  by  adding 
those  remaining  from  the  inherited  assets  to  those  which  exist  as  a 
result  of  new  purchases,  that  is, 


wdlm  + 


XJJ 4 


where  =  number  of  subperiods  before  the  start  of  the  planning  period 

i.u 

from  which  the  J  type  of  machine  1b  inherited.  Note  that 
(i  -  K . , . . . , -1,0)  in  the  first  series  set  above  but  (tf  •  1,2,... t)  in 
the  second  series  set.  Y  -  number  of  Bubperiods  in  the  planning  hori¬ 
zon  ( l  •>  1,2, . . .  ,Y) .  The  factor  v^/j  accounts  for  attrition  due  to 
accidental  loss  of  machines  and  specifically  represents  that  fraction 
of  type  J  machines  whloh  remain  usable  after  i-i'  subperiods  of  existence. 

The  nuoiber  of  the  j  type  maohines  required  in  subperiod  l  is  ob¬ 
tained  by  summing  over  all  units  used  to  satisfy  eaoh  mission  group.  This 
summation  is  expressed  as 


uijki  piJ a 


where  M|  is  the  set  of  different  mission  groups  in  subperiod  i,  R^ 
is  the  number  of  alternative  ways  of  performing  mission  group  l  in 
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subperiod  is  the  number  of  times  mission  group  i  must  be  inde¬ 

pendently  performed  in  subperiod  4,  and  u,  is  the  number  of  units 
of  the  J  equipment  used  in  performing  mission  group  1  with  the  k 
alternative  in  subperiod  4. 

th 

The  oonstraint  relation  insures  that  the  number  of  J  type 
mao hi nos  that  we  have  on  hand  for  use  in  subperiod  4  must  be  greater 
than  ?r  equal  to  the  number  required.  Expressed  as  an  equality,  this 


relation  is: 


0  Y 


4  Y 


Y  Y  "j4  *  V  Y  ^ ^  ■ 

fcr  sr  fcr  fcr 


I  1  ■ 


i  jki  +  BH 


for  j  -  1,2, ... ,N 
and  4  ■  1,2, ...  ,Y 


where  s^  is  a  slaok  variable  whloh  is  specifically  included  because  it 
has  a  physical  meaning  in  the  problem}  it  represents  aaohlnes  of  the 
type  which  can  be  "mothballed"  in  subperiod  4  for  later  use. 

Consistency  Constraints 

The  second  subset  of  constraints  Insures  that  the  requirements  of 
eaoh  mission  group  are  met.  This  is  accomplished  by  requiring  that  the 
fractions  or  proportions  used  for  eaoh  of  the  alternatives  within  a 
given  mission  group  do  sum  to  1.0.  The  oonstraint  set  then  takes  the 


form: 


It  fhould  be  emphasized  that  the  formulation  of  the  consistency 
constraints  in  this  manner  actually  represents  the  assumption  that  all 
convex  combinations  of  alternatives  are  equally  effective.  This 
assumption  introduces  two  points  of  concern:  (l)  In  most  oases  this 
assumption  will  result  in  a  fractional  number  of  machines  in  the  optimal 
solution,  requiring  the  user  to  readjust  the  solution  to  the  nearest 
"whole"  machine(s)— -this  interpretation  of  fractional  solutions  will 
cause  no  large  errors  as  long  as  the  number  of  machines  of  each  type  is 
large,  relative  to  one;  and  (2)  this  assumption  may  result  in  the  choice 
of  a  particular  convex  combination  which  differs  significantly  from  that 
of  an  equally  effective  alternative.  The  seriousness  of  this  problem  can 
only  be  determined  by  a  study  of  a  series  of  typical  problems.  Until 
such  further  study  is  conducted,  it  can  only  be  noted  that,  to  date,  no 
serious  departures  from  equal  effectiveness  have  been  observed  in  the 
problems  which  have  been  solved. 

Vintage  Constraints 

The  next  set  of  constraint  relations  accomplishes  two  purposes; 

(1)  they  define  the  inherited  assets  in  terms  of  both  number  and  vintage 
(age)  and,  (2)  they  relate  these  numbers  to  the  ultimate  disposition  of 
the  assets  to  ensure  that  all  are  accounted  for.  These  relations  are 
given  by  the  equations: 

u  ■  )  w  .  J  ■  1,2,. ..,N 

J*  &o  itm  *  1  "  Kj,Kj+1,.*.,-1»0 

where  Lj  is  the  maximum  life  (in  subperiods)  of  machine  type  j,  and 
is  the  number  of  type  j  machines  inherited  from  subperiod  4. 
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Master  Variable  Relation  Constraints 

We  define  Xj  to  ba  the  total  number  of  naohlnaa  of  type  J  purofaaaad 
during  tha  ant Ire  planning  parlod.  Wa  can  obtain  by  summing  tha 
subordinate  variables  over  all  i  and  a,  tha  purohaaa  and  disposal 
subparlods. 

Y  Y 

*)-  I  I  *31*  ‘  J*1’2’  —  '  * 

X"  1  m-X 

These  constraints  not  only  define  tha  master  variables  but  also  maintain 
"separability"  In  tha  cost  function  as  discussed  on  page  3-LO. 

Cost  Constraints 

Specifically  at  this  point  ve  discuss  and  describe  tha  Implementation 

of  linear  procurement  constraints.  Similar  constraints  oould  be  considered 

for  operating  oosts  but  their  Implementation  would  require  program  changes. 

This  constraint  restricts  the  total  purchase  In  subperiod  l  to  be  lesa 

than  or  equal  to  some  fixed  ceiling,  H,,  for  procurement  In  that  subperiod. 

The  constraint  relation  auievs  for  any  funds  left  over  at  the  end  of  sub- 

period  l  to  be  transferred  for  use  in  subperlod  1  +  1.  This  Is  given  as 

N  Y 

HX  "  I  a°d  I  xJXm  +  PX  "  pi-l 
J-l  m ml 


for  i  -  1,2,..., Y 

where  is  the  slack  variable  representing  the  surplus  funds,  and  a° 

Is  the  linear  cost  coefficient  (vhloh  may  represent  an  approximation  If 
the  aost  function  is  nonlinear).  This  constraint  set  Is  Intended  to  be 
Incorporated  as  an  optional  feature  slnoe  Its  use  may  very  well  result  In 
an  Infeasible  problem. 
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TKS  0BJV7TIVX  FUHOTION 

Six  dietinot  oort  oategorlea  art  included  within  ths  objective 
fun ot ion,  Th*  thro#  primary  oategorisa  art  research  and  development 
(BAD),  procurement,  and  operating  expense.  Th*  secondary  oategorlaa  ar* 
aoat  appropriately  named  mothballing,  salvage,  and  truncation  ooata 
(th*»*  tmi  will  b*  d*fln*d  in  a  subsequent  paragraph) .  For  purpoaaa 
of  thla  development,  only  th*  RAD  and  procurement  coat  function*  ar* 
oonald*r*d  to  b*  aonoavej  however,  from  a  modeling  point  of  view  there 
la  no  r«aaon  why  any  of  the  other  categories  could  not  also  be  defined 
by  oonoav*  function*. 

Primary  Coat  Ckteaoriea 

Th*  BAD  function  can  be  represented  by  a  step  discontinuity  at 
aero.  W*  will  designate  this  function  as  Uj  (x^).  Then  (x^)  ■  0  if 
the  master  variable  Xj  -  0,  and  Uj  (xj)  -  (son*  constant)  if  x^>  o. 

D,  is  th*  estimated  BAD  coat  for  machlna  type  J.  The  total  RAD  cost  ia 
obtained  by  euanlng  over  all  machine  types, 

l  uj  uj> 

J-l  . 


and  this  is  th*  first  type  of  term  in  th*  objective  function. 

Procurement  le  defined  in  term*  of  a  so-called  "learning  curve" 

bj 

and  can  in  most  cases,  be  represented  by  the  function  e^x^  ;  where  a^ 
is  th*  cost  of  buying  one  machine  of  type  J,  and  0  <  b^  *  1.  Thla  function 
auggects  that  although  the  total  cost  increases  as  the  buy  ala*  increases, 
th*  unit  cost  la  actually  decreasing  (except  for  the  linear  case  when 
b,  -  l).  Th*  total  expenditure  for  procurement  is  then, 
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Since  v«  distinguish  bstwssn  the  Inherited  and  purchased  machines, 

It  Is  necessary  to  develop  tvo  separate  expressions  for  operating  cost. 

We  define  for  use  In  both  expressions  the  oost  coefficient  o^,  i.e., 

XU  i,V 

the  oost  of  operating  one  unit  of  the  j  type  In  Its  k  subperiod  of 
existence.  This  allows  for  an  lnorease  In  operating  oost  based  on  the 
age  of  the  equipment. 

Starting  with  the  new  equipment,  we  wish  to  formulate  the  operating 

oosts  In  terms  of  variables  of  the  type  Xj^.  Recall  that  x^  represents 

the  number  of  units  purchased  at  the  beginning  of  subperiod  4  and  disposed 

of  at  the  end  of  subperiod  m.  Then  the  lifetime  of  x^  machines  Is 

a  -  4  +  1  subperiods,  and  the  total  operating  oost  for  these  maohlnes  is 

the  sum  of  the  oosts  for  eaoh  subperiod,  that  1st 

a*  4+1 

£  xJAs 
k-1 

ty  tuning  over  all  subperiods  and  machine  types,  we  derive  the  total 
operating  oost  for  the  new  aaohlnes  over  the  entire  planning  period. 

This  ra  Is 

H  X  Y  a- 4+1 

1111  v 

J-l  4-1  nl  k-1 

The  operating  oost  of  the  Inherited  assets  Is  oaloulated  similarly. 
The  ooet  of  a  given  variable,  v^,  Is 

a- 4+1 

1  »ji» 

k-2-4 


l 

l 

X 


where  the  summation  begins  at  2  -  4  since  4  here  Is  neptlve  or  aero  and 
the  first  subperiod  of  the  planning  period  must  be  at  least  the  seoood 
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subperiod  of  the  machines  life.  The  total  operating  cost  is  again 
obtained  by  summing  over  tho  subperiods  and  machine  types;  that  is, 


N 

0  Y  m-A+1 

I 

ILL  °jk  wJim 

J-l 

A»K  m»l  k-2-£ 

J 

Secondary  Cost  Categories 

Each  of  the  primary  categories  represents  a  specific  cost  (outlay 
of  dollars).  In  contrast,  each  of  the  secondary  categories  represents  a 
type  of  savings  or  credit  to  the  system.  "Mothballing"  is  herein  defined 
as  the  storage  of  equipment  (owned  but  not  presently  needed)  for  use  at 
a  later  time.  In  the  prerent  formulation,  we  associate  a  savings  with 
this  storage  resulting  from  a  decrease  in  operating  cost  (i.e.,  we 
initially-  charged  the  full  operating  cost  for  all  retained  machines). 
"Salvage"  is  the  refund  received  from  the  sale  of  equipment  which  is  no 
longer  needed.  Finally,  "truncation"  is  a  credit  for  the  value  of  the 
equipment  on  hand  at  the  end  of  the  planning  period.  It  is  used  to 
compensate  for  the  fact  that  we  only  consider  a  finite  time  period  and 
have  no  real  knowledge  concerning  the  use  of  the  equipment  after  that 
time.  In  the  current  formulation  of  the  model  we  have  assumed  that  each 
of  these  three  secondary  cost  categories  can  be  approximated  by  linear 
cost  expressions— this  is  not  meant  to  imply  a  restriction;  more  complex 
aost  expressions  may  be  used. 

The  mothballing  variable,  s^,  was  previously  defined  by  the 

materiel  balance  constraints.  The  total  cost  (actually  a  negative  oost, 

or  savings)  resulting  from  mothballing  is 

N  Y 

l  l  <  -V  ‘i* 

>1  A- 1 
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where  d. .  Is  the  unit  refund  for  mothballing  a  type  J  machine  in  suhperiod 
J* 


Savings  due  to  naohlne  salvage  must  be  calculated  for  both  the 
inherited  and  the  new  equipment,  as  was  done  for  operating  oosts.  The 
machines  represented  byx^  are  salvages  after  a  -  l  +  1  subperiods  of 
service,  providing  that  a  #  Y  (if  m  -  Y,  they  would  be  truncated  Instead 
of  salvaged) .  We  define  (m  -  i  +  l)  aB  the  “^^S®  value  of  a  type  J 
machine  after  m  -  i  +  1  subperiods  of  use.  The  total  savings  from 


salvage  is  then 


N  Y-l  Y-l 

III  ("eJ  (m  -  l  +  I)*  XJ 

J«1  X«1  m ml 


Similarly  the  savings  resulting  from  salvage  of  the  inherited  assets  is 


given  by  the  sum 


N  0  Y-l 


1  1  1  (a  -  4  +  1)J 


>1  A-K,  m-0 


Credit  for  truncation  is  calculated  from  the  candidate  solution 
at  the  end  of  the  planning  period;  that  is,  when  m  ■  Y.  Henoe,  the 
maohlnes  are  Y  -  t  +  1  subperiods  old.  We  define  f^  _  ^  +  ^ 

as  the  oredlt  added  for  a  type  J  machine  after  Y  -  i  +  1  subperlods.  The 
truncation  oredlt  (introduced  as  a  minus  quantity  In  the  oost  function) 


is  then 


N  Y 

I  I  (Y  -  i  +  lp  XJ 

>1  i-1 


for  the  purchased  equipment,  and 


N  o 

I  L  (Y  -  l  +  1)*  wJim 

>1  Jt-Kj 

for  the  inherited  equipment . 

This  completes  the  development  of  the  cost  expression*}  the  entire 
cost  function  is  shown  in  Fig.  3.1, 

THE  SOLUTION  PROCEDURE 

There  are  two  special  restrictions  in  the  cost  function  that  are 
essential  to  the  bnanch-and-bound  solution  procedure.  First,  the  function 
must  be  "separable"  meaning  that  each  variable  must  be  priced  separately 
(each  cost  expression  must  be  a  function  of  a  single  variable)  --  this  is 
the  reason  for  the  development  of  the  master  variable  relation  constraint; 
otherwise  the  R&D  and  procurement  costs  would  be  a  function  of  a  sum  of 
variables.  The  second  restriction  Is  that  all  of  the  separable  functions 
which  make  up  the  cost  function  must  be  concave*.  For  functions  of  a 
single  variable,  this  means  that  a  straight  line  drawn  between  any  two 
points  on  the  graph  of  the  function  always  has  a  value  which  Is  less  than 
or  equal  to  the  value  of  the  function.  A  linear  function  Is  then  a 
special  case  of  a  concave  function. 


*In  mathematical  notation  a  function  f(x^, ...,  x^)  is  concave  If 
for  any  two  points  (x£,  ...,  x^)  and  (x^',  ...,  x^' ),  and  any  t,  0  <  t  <  1, 
f[tx£  +  (l-t)x£»,...,  tx^  +  (l-t)x^'l  *  tf(x£,...,  x£)  +  (l-t)  f(x£',  ..., 

*4’>- 
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In  addition,  there  m  three  special  characteristics  of  tho 
constraint  set  vhloh  should  be  noted t  (l)  all  of  the  constraint  equations 


are  linear,  (2)  the  constraint  set  is  closed*,  and  (3)  the  problem 

variables  can  be  bounded  from  above  and  below.  It  can  be  shown  that  the 

problem  as  described  above  is  but  <  special  case  of  the  general  non -convex 

2 

programming  problem  addressed  by  Falk  and  Soland  .  We  can  apply  their 
solution  algorithm  to  this  problem  by  solving  a  sequence  of  linear  program¬ 
ming  (LP)  sub-problems. 

We  define  a  vector  of  upper  bounds  L  -  (L^,  Lg,  ...,  Ly  ...,  1^) 
on  the  master  variables  x^  such  that 

0  s  xj  s  V  J  * lf  2*  •••» N 


and  note  that  these  bounds  can  be  obtained  directly  from  the  input  tableau 
(e.g.,  Fig.  1-3).  These  lower  and  upper  bounds  define  a  set  of  N  closed 
intervals  which  we  will  refer  to  as  set  C.  We  need  only  explicitly  define 
upper  bounds  on  the  master  variables  x^  since  these  are  the  only  bounds 
used  in  the  solution  procedure— the  remaining  problem  variables  have 
implicit  bounds  which  can  be  derived  from  the  master  variable  bounds  for 
the  x^m  variables,  from  the  consistency  constraints  for  the  p^t  variables, 
and  from  the  vintage  constraints  for  tho  w^  variables. 

Linear  Envelopes 

Having  defined  the  set  C,  we  next  construct  a  "linear  envelope" 
for  the  cost  function  aczoss  that  set.  This  moans  that  for  eaoh  nonlinear 
contribution  to  the  cost  function,  we  define  a  linear  function  which  is 


♦Specifically,  a  closed  set  is  one  in  whioh  the  boundaries  are 
Included  in  the  set;  that  is,  there  are  no  constraint  equations  involving 
strlot  inequalities. 
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the  best  linear  underestimate  of  tho  oonoavo  function.  This  can  be 
dona  graphically  by  constructing  the  straight  line  from  the  two  and 
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points  of  tha  oonoavs  function  aoross  ths  interval  defined  by  C. 


Fig.  3*2— A  Linear  litvalapa  of  a  Concave  Function 
with  Dlccantlnulty  at  Origin 


We  next  construct  an  estimating  sub-problem  by  replacing  each 

concave  Lost  function  with  its  linear  envelope.  Our  objective  function 

is  now  linear  and  thus  a  linear  programming  problem  is  defined.  This 

linear  programming  problem  can,  of  course,  be  solved  but  we  will  not 

discuss  its  solution  in  detail.  We  only  mention  that  a  "revised  simplex" 

algorithm  incorporating  "generalised  upper  bounding"  Is  used.  A  detailed 

3 

description  of  this  method  is  presented  by  Beale. 

Bounding  the  Solution 

Since  any  solution  to  the  linear  problem  underestimates  the  cost 
function  of  our  original  problem  for  that  solution  vector,  the  solution 
to  the  linear  programing  problem  provides  a  lover  bound  on  the  solution 
of  the  non-linear  programing  (NLF)  problem.  This  can  be  shown  algebraically 
by  letting  f  represent  the  objective  function  of  the  LP,  then 

f  (x)  *  0  (x) 


I 
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for  all  x  €  0.  Vov  If  wo  lot  x*  repress nt  the  solution  vector  to  the  II, 
and  x*  represent  tha  aolution  vaotor  to  tha  MLB,  than  ainoa 


for  all  x  €  C,  than 


or,  moat  Importantly 


f(x»)  *  f(x) 

0(x»)  *  0  (x) 

f(x')  *  f(x*)  *  0  (x#)  *■  0  (x) 
f(x')**(x*) 


Thla  also  implies  that  the  solution  to  the  LP  in  a  given  subset  is  a 
lower  bound  to  the  NLP  within  that  subset. 

Similarly,  it  can  be  argued  that  tha  actual  value  of  the  non¬ 
linear  cost  function  at  the  solution  vector  of  the  LP  is  an  upper  bound 
on  the  solution  to  the  NLP.  That  is, 

0(x' )  *  0(x*) 

Therefore,  bounds  can  bo  established  on  tha  solution  to  the  problem 
since 

f(x»)  M  (x»)  M  (x») 

Jr 

The  object  of  the  algorithm  is  to  find  a  solution  vector  x  by  solving 
a  sequence  of  m  sub-problems  -  id  to  show  that 

0(x  )  ^  0(x  )  !  i  ■  1,2,  ...  k,  ...  m 

and 

f(xJ)  a  *  (xk) 


for  all  J  such  that  the  subsets  Cj  form  some  partition  of  C.  It  has  been 
shown  that  this  sequence  of  sub-problems  is  finite  (Falk  and  Soland, 

Theorem  3)  and  that  x1  converges  to,  and  terminates  at  x#  for  the  restrictions 


previously  stated. 
Partitioning  Into  Subsets 
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The  sequence  of  sub -problems  are  generated  by  a  branehHUid-bound 
procedure .  This  procedure  suooesslvely  partitions  the  original  set  C 
into  smaller  and  smaller  subsets,  eaoh  of  which  is  defined  by  upper  and 
lower  bounds  on  the  master  variables.  Further,  eaoh  subset  defines  a 
LP  sub-problem  and  its  linear  envelope  provides  a  better  underestimate 
aoross  the  subset  than  that  provided  by  the  linear  envelope  of  the  pre- 

o 

ceding  problem.  The  specific  method  of  partitioning  Is  the  Falk-Boland 
"weak  refining  rule".  Given  that  we  have  the  solution  to  any  sub-problem 
x?1  -  (x®,  xJJ,  . ..,  x®),  then  the  weak  refining  rule  states  that  one  should 
select  the  partitioning  variable  to  be  x^  if  the  difference  between  the 
value  of  the  concave  function  at  x®  and  the  value  of  the  linear  under¬ 
estimate  at  xf  is  at  least  as  great  as  the  corresponding  difference  for 
any  other  x®,  where  J  /  i.  That  is,  seleot  that  vhloh  satisfies 

*i  (*“)  (*?)  -  Max{^  (^J)*  J  -  h2*  •••»  N} 

This  gives  us  the  variable  on  which  to  branch  and  partition  the  set 

into  two  subsets  C'  and  C’ ' .  In  general  the  set  C  is  defined  by 
m  n  hi 

J(D  <  x  i  Lm 

where  ^  is  the  lower  bound  vector,  L®  is  the  upper  bound  vector,  and 

4®  *  L®  for  all  i.  We  wish  to  divide  the  interval  [4®,  L®]  for  the 

variable  xi  at  the  value  x^.  This  means  that  the  variable  will  range 

across  the  sub-interval  [4®,  x®]  in  set  C',  and  across  the  sub-interval 

taf,  L®]  in  set  C".  Then  set  C"  is  defined  by 
11  in  in 
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$ ....  <)*»«*"  -* 

and  the  aat  C'  by 

n 

/»'  .  *"  <  x  *  iB'  -  (15,  15,  ....  *j,  ....  if) 

Wa  have  now  partitioned  the  eat  Cffi  Into  two  subsets  and  In  effect  oreated 
two  new  aub-problama  to  be  solved. 

The  Algorithm 

Thus  far,  each  major  procedure  of  the  algorithm  haa  been  dlaouaaed. 

We  now  show  their  relatlonahlp  to  eaoh  other  by  presenting  the  baaio 

cycle  of  the  algorithm  (aee  Fig.  3  -3).  We  begin  by  aeeumlng  that  we  are 

about  to  partition  a  sub-problem  defined  by  the  subset  C^,  and  that  we 

have  determined  (by  the  weak  refining  rule)  the  variable  x®  on  whloh  to 

branch.  Two  new  subsets  C'  and  C”  are  formed.  We  then  oonatruot  the 

n  m 

linear  envelope  across  CM  (block  5  of  Fig.  3-3)  and  aolve  the  corresponding 
LP  to  obtain  the  solution  vector  xm*  and  the  cost  f  (X®' ) .  We  determine 
a  variable  on  which  to  branoh.  We  next  oompute  the  value  of  0  (x®' ) 
and  compare  this  value  with  the  value  of  0  (x° ),  where  0  (xP)  is  the  best 
solution  found  thus  far  (the  reference  solution).  If  0  (x®  )  <  0  (x°), 
then  we  update  and  replace  0  (xP)  with  0  (x®' ) .  We  then  store  the 
problem  description  along  with  the  values  x®  and  f  (x®  )  on  a  branching 
list.  The  process  is  repeated  for  the  subset  C"  and  its  information  is 

m 

stored  on  the  branching  list.  We  then  select  and  remove  that  sub-problem, 

,  from  the  branching  list  such  that  f  (xa)  ■  Min  |f  (x*)j  for  all  kj 
and  the  cycle  repeats. 

Given  Just  this  cycle,  the  algorithm  would  run  forever.  We  need, 
therefore,  define  some  type  of  termination  criteria.  First,  if  when  we 
solve  the  LP  problem  defined  by  C ,  we  find  that  f  (xm)  s  0  (x°)  then  we 
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Fig.  3*3 — THo  Algorithm 
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know  that  no  solution  better  than  0  (xr)  exists  In  the  subset  0..  Bo 
we  discard  th#  aubaat  from  further  consideration  (block  4  of  Fig.  3*3)  *nd 
aalaot  the  next  problem  on  the  branching  llat.  Finally,  vhen  there  are 
no  more  problama  on  the  branching  Hat,  we  know  that 

0  (]f)  -  0  (x*),  and  yf  -  x*,  alnoe  0  (a?)  a  0  (x)  for  all  x  In  0. 

2 

In  Theorem  3  of  their  paper  ,  Falk  and  Boland  prove  that  thla 
algorithm  converges  to  the  aolutlon  of  the  problem  with  a  finite  lumber 
of  sub -problems.  It  ahould  be  noted  that  the  term  finite  does  not  oonoem 
Itself  with  the  number  of  sub-problams  required  for  oonvergenoe,  and  that 
In  some  cases  It  may  be  expedient  to  only  ensure  that  the  aolutlon  obtained 
is  within  acme  small  tolerance  of  the  optimal  aolutlon  (for  example i 
within  0.l£  of  the  optimal  solution).  Thla  la  easily  aooompllahed  by 
adjusting  the  termination  criteria  to  dieeard  a  aubaat  If 

f  (x^1)  at  0  (**)/  (l  +  tolerance  faotor) 

It  Is  considered  important  to  review  and  to  emphasise  here  that 
Implementations  of  this  optimisation  model,  and  the  resulting  solutions, 
are  subject  to  certain  assumptions  whloh  must  be  carefully  observed  and 
understood.  These  assumptions  are  necessary  for  either  of  two  reasons i 
(l)  the  alternatives  to  the  particular  assumption  are  economically 
prohibitive,  or  (2)  the  teohnloal  restrictions  in  the  algorithm  itself 
cannot  be  waived  by  any  reasonable  scheme.  A  brief  review  of  the  model 
assumptions,  and  a  reference  to  their  detailed  descriptions  follows! 

(l)  The  cost-quantity  relationship  of  a  particular  type  vehicle 
(machine)  must  be  concave  and  independent  of  the  state  of  a  vehicle  of 
another  type  —  see  pages  3-5  and  3-10. 
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(2)  Vehicles  used  to  satisfy  the  requirements  of  one  mission 
group  cannot  be  used  (pooled)  In  any  other  mission  group  —  set  pa« 


(3)  All  oonvex  combinations  of  the  finite  list  of  user •supplied 
equally  effective  alternatives  are  also  equally  effective  — -  see  page 


i 
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Chapter  4 

AN  OPERATIONAL  DESCRIPTION  OF  THE 
BRANCH  AND  BOUND  SOLUTION  PROCEDURE 

Shortly  after  the  ooaputer  program  development  began  it  became 
apparent  that  beoauee  of  the  complexity  of  the  solution  procedure  and 
the  magnitude  of  the  problems  to  be  solved,  it  would  be  necessary  to 
sub-divide  the  solution  procedure  into  tvo  separate  programs;  namely , 
the  matrix  generator  (OENLCP  for  QENerate  Least  Cost  Phasing)  and  the 
main  program  (BBCAV2  for  Branch-and-£ound  conCAV  functions  version  2) . 
However,  as  work  on  BBCAV2  progressed,  it  was  seen  that  the  output  was 
very  much  technically  oriented  and  that  this  orientation  was  essential 
for  debugging,  detecting  input  errors,  and  traoing  the  flow  through 
the  development  of  the  "branching  tree."  Because  of  the  necessity 
of  this  output  and  the  desirability  for  a  less  technical  report,  a  third 
program  (REPGEN  for  REPort  OENerator)  was  developed  to  display  the 
optimal  and  relevant  off -optimal  solutions  in  a  manner  which  would  be 
easy  to  understand.  Thus  the  present  operational  system  consists  of 
these  three  programs  named  with  the  mnemonics  GENLCP,  BBCAV2,  and  HEPOEN. 

PROORAM  INTERFACING 

The  major  problem  encountered  by  using  separate  programs  is  that 
of  passing  large  data  files  from  one  program  to  another.  The  matrix 
generator  creates  the  matrix  file  which  must  be  passed  to  the  main  pro¬ 
gram  and  a  reference  list  file  which  must  be  passed  to  the  report  genera¬ 
tor  so  that  it  can  process  the  solutions.  The  main  program  then  creates 
a  solution  file  which  of  course  must  be  passed  to  the  report  generator.  The 
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exact  oontoot  iqA  structure  of  those  file*  irlU  bo  discussed  la  a  labor 
Motion  of  this  ohaptor. 

Tho  lntorfaolac  of  tbo  proem*  1*  sclcly  dependent  on  tbo  trans- 
for  of  th*M  files,  and  this  1*  aooa^lisbed  by  th*  um  of  olthtr  a 


physical  or  a  logical  tap*  flit  which  1*  manipulated  by 
operating  system  o octroi  oards.* 


of  tbo 


KKFOBf  1*  oaoily  executed  within  tbo  ooao  oooputor  job  a*  HBQAV2, 
thoroforo  thoro  aro  at  loast  two  Job  configuration*  available  to  tbo  uaor. 
They  aroi 

(1)  CBHLCP  can  bo  exeouted  first  a*  on*  job,  while  program  BBCAV2 
and  REFCBBI  aro  executed  later  as  two  program  within  a  second  Job.  Boo 
Figure  4 -la  for  tbo  CDC  6400  control  cards. 

(2)  OBOjGP,  HBGAV2,  and  RKFOBf  can  bo  oxooutod  as  throe  different 
program  within  one  Job.  Boo  Figure  4-lb  for  tbo  necessary  CDG6400 
control  cards. 

Each  Job  has  tho  following  control  card  typos;  a  Job,  a  RUN(8),  and 
a  LOO  card.  The  Job  card  merely  describes  th*  job  to  the  system,  the 
RUN(S)  card  executes  the  FORTRAN  compiler,  and  the  LOO  card  loads  and 
executes  th*  compiled  program.  Each  job  also  has  a  request  card,  which 
requests  the  same  tape,  meaning  that  the  x's  In  the  parentheses  are  replaced 
by  the  same  tape  number  on  all  request  cards. 

Upon  execution  the  matrix  generator  creates  the  matrix  on  file  9 
(TAFE9),  and  the  reference  list  on  file  7  (TAPE7).  After  the  physical 


♦This  report  describee  the  use  of  CDC  6400  control  cards  for  tape 
file  manipulation.  Implementation  of  this  program(s)  on  other  computing 
machines  will  require  appropriate  changes  to  the  control  card  set. 


MATRIX  GENERATOR,  MAIN  PROGRAM  AND  REPORT  GENERATOR 


"Job  Card" 
run(s) 

LG0. 

REQUEST,  TAPEA,  HI.  (XXXX/RINO)# 
REWIND  (TAPE7,  TAPE9,  TAPIA,  LQ0) 
C0PTCF  (TAPE9,  TAPIA) 

0OFYCF  (TAPE7,  TAPEA) 

REWIND  (TAPEA) 

RUN(S) 

■LG0. 

REWIND  (TAPE8,  TAPEA,  LO0) 

C0FYCF  (TAPEA,  DM1,  2) 

C0FYC?  (TAPE8,  TAPEA) 

REWIND  (TAPEA) 

C0FYC?  (TAPEA,  DM1) 

RUN(S) 

LG0. 


*  If  TAPEA  Is  only  a  logical  tape  file  that  Is  not 
saved  at  the  end  of  this  Job,  then  this  control 
card  can  be  omitted. 


Fig.  4-la  Controls  Cards  to  Execute  All  Programs 
as  a  Single  Job 
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MATRIX  GENERATOR 


"Jbb  Card  #1" 

RUN(S) 

LO0. 

REQUEST,  TAPEA,  HI.  (XXXX/RING) 
REWIND  (TAPE7,  TAPE9,  TAPEA) 
C0PICP  (TAPE9,  TAPEA) 

C0PICP  (TAPE?,  TAPEA) 

MAIN  PROGRAM  AND  REPORT  GENERATOR 

"Job  Card  #2" 

RUN(a) 

REQUEST,  TAPEA,  HI.  (XXXX/RING) 
LG0. 

REWIND  (TAPE8,  TAPEA,  LO0) 

C0FIC?  (TAPEA,  DM1,  2) 

C0FICF  (TAPE8,  TAPEA) 

REWIND  (TAPEA) 

C0PYCF  (TAPEA,  DM1 ) 

run(s) 

LC0. 


Pig.  U-lb  Control  Cards  to  Execute  Programs 
as  Separate  Jobs 


tap*  i*  requested!  the  tap*  and  both  files  are  rewound  to  th*ir  load 
points  by  th*  REWIND  card,  and  than  th*  files  ar*  aopied,  matrix  fll* 
first,  onto  fll*  A  (TAPEA)  in  coded,  rather  than  binary,  format  through 
th*  us*  of  th*  COFTCF  oards. 

TAPEA  Is  then  transf*r*d  to  th*  main  program  and  th*  first  fll* 

Is  read  during  execution.  Th*  main  program  or*at*s  the  solution  fll*  on 
TAPES.  Upon  completion  of  th*  execution  of  BBCAV2,  TAPE8  and  TAPEA  are 
rewound.  The  matrix  and  r*f*r*nc*  list  files  on  TAPEA  ar*  then  copied 
onto  dummy  files  In  order  to  space  to  th*  end  of  the  tape  file  and  the 
solution  file  Is  copied  onto  the  end  of  TAPEA. 

Th*  report  generator  only  uses  the  last  two  files  on  the  tape,  so 
before  It  executes  the  first  file  It  Is  copied  onto  a  dummy  file .  The 
program  then  reads  the  last  two  files  as  It  executes.  The  total  Interfacing 
of  the  programs  is  shown  in  the  macro  flowchart  of  the  system.  Fig.  4.2. 

THE  MATRIX  GENERATOR 
Program  Logic 

This  program  produces  as  its  main  output  the  matrix  of  coefficients 
for  the  phasing  problem.  Essentially  the  program  reads  the  input  deck 
and  then  determines  the  number  of  constraints  (rows)  and  the  number  of 
variables  (columns)  for  the  problem.  In  order  to  facilitate  communication 
between  programs  and  between  the  program  and  the  analyst,  this  program 
assigns  symbolic  names  to  the  rows  and  columns.  These  symbolic  names 
can  then  be  decoded  to  determine  exactly  what  that  column  (row)  represents. 
The  naming  convention  which  the  program  uses  is  shown  in  Fig.  4-3.  These 
symbolic  names  are  generated  through  the  use  of  the  array  NP.  This  array 
contains  a  positive  integer  code  for  the  integers  1-288  (288  is  the  largest 
integer  used  by  the  program),  and  this  code  is  shown  in  Fig.  4-4.  This 
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Integers 


Codes 


01  - 

99 

01  -  99 

100  - 

109 

AO  -  A9 

110  - 

119 

BO  -  B9 

120  - 

x29 

CO  -  C9 

130  - 

139 

DO  -  D9 

l4o  - 

149 

EO  -  E9 

150  - 

159 

FO  -  F9 

160  - 

169 

GO  -  G9 

170  - 

179 

HO  -  H9 

180  - 

189 

JO  -  J9 

190  - 

199 

KO  -  K9 

200  - 

209 

LO  -  L9 

210  - 

219 

MO  -  M9 

220  - 

229 

NO  -  N9 

230  - 

239 

PO  -  P9 

240  - 

249 

QO  -  Q9 

250  - 

259 

RO  -  R9 

260  - 

269 

TO  -  T9 

270  - 

279 

UO  -  U9 

280  - 

288 

§ 

■ 

0 

at 

Fig. 4-4  Positive  Integer  Code 
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code  replaces  the  integer  values  indicated  by  the  subscript  in  the 
naming  convention. 

The  program  next  determines  the  value  of  all  of  the  non-zero 
elements  of  the  matrix.  As  it  determines  these  values  it  creates  a 
"packed  and  labeled"  matrix  file;  packed  meaning  it  contains  no  zero 
valued  elements ,  and  labeled  meaning  it  has  associated  with  each  element 
its  row  and  column  names.  In  order  that  this  packed  file  be  created  in 
some  standard  format,  it  was  decided  that  MPS36O  format  be  used.  This 
has  the  advantage  that  should  one  wish  to  use  this  file  on  other 
mathematical  programing  systems,  it  is  in  a  format  acceptable  to  both 
IBM  and  CDC  systems. 

After  this  file  is  created,  the  program  then  fills  in  the  zero¬ 
valued  elements  and  creates  an  unpacked  and  unlabeled  file  which  is  the 
input  matrix  to  BBCAV2.  At  this  point  it  also  creates  the  reference 
list  which  indicates  the  symbolic  name  to  be  associated  with  each  column 
of  the  unlabeled  file. 

Core  Allocations 

The  program  requires  107,300  octal  (36,544  decimal)  words  of  core 
on  the  CDC  6400  system  in  order  to  load.  Almost  two-thirds  of  this  is 
used  for  common  storage;  most  of  which  is  in  the  form  of  subscripted 
arrays.  These  arrays  are  presently  dimensioned  to  handle  the  following 
size  problems; 

(1)  number  of  machines  (vehicles)  £  7 

(2)  number  of  task  tables  £  8 

(3)  number  of  periods  £  10 

(4)  number  of  alternatives  in  a  task  £  288 

(3)  number  of  years  from  which  vehicles  are  inherited  £  16 
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(6)  maximum  vehicle  life  £  25 

(7)  maximum  length  of  a  period  £  6 


Any  of  these  which  are  exceeded  will  necessarily  cause  changes  in  the 
subscripted  arrays  and  core  storage  requirements. 

The  core  storage  allocation  can  be  broken  up  into  the  following 


subgroups: 

OCTAL 

DECIMAL 

CDC  system  routines 

=  13,210 

5,768 

COMMON  storage 

53,562 

21,362 

GENLCP 

»  20,323 

8,403 

MATFILL 

1,415 

781 

YINTERP 

=  207 

135 

YRCOST 

=  137 

95 

TOTAL 

107,300 

36,544 

User's  Subroutine  -  YRCOST 

This  subroutine  is  used  to  calculate  operating,  mothballing, 
salvage  and  truncation  costs  based  on  the  age  of  a  vehicle.  For  everything 
but  mothballing,  this  Is  accomplished  by  filling  the  array  COSTS  with  the 
yearly  costs  for  a  vehicle  up  to  an  age  of  30  years.  The  main  routine 
Just  selects  the  appropriate  cost  from  this  array  as  it  is  needed.  For 
mothballing,  however,  the  routine  is  called  each  time  a  value  is  needed, 
and  only  the  mothballing  cost  is  calculated.  This  is  done  through  the 
use  of  the  ENTRY  MOTH  statement. 

Operating  costs  are  assumed  to  be  increasing  at  R  x  100  percent 
each  year  (not  compounded),  with  R  presently  set  equal  to  zero.  It  is 
noted  that  the  present  formulation  for  operating  costs  does  not  account 


for  the  attrition  of  aircraft  over  the  years;  such  account  is  handled. 

explicitly  through  the  materiel  balance  constraints  in  Chapter  3*  If  the 

user  has  10  year  operating  costs  which  already  include  costs  for  attrition, 

then  V.  ...  should  be  set  equal  to  1.0.  Note  also  that  it  is  assumed  that 
4-4'  J 

no  period  is  longer  than  six  years.  If  a  period  is,  it  will  be  necessary 
to  change  this  card  in  subroutine  YRC0ST. 

IB  =  VLIFE  (J)  +  10 
to 

I.  -  VLIFE  (J)  +  (N  -  1) 

where  N  is  the  number  of  years  in  the  longest  period  (IB  cannot  exceed 
30  in  any  case) .  Salvage  values  are  calculated  to  be  alpha  to  the  ith 
power  times  the  initial  salvage  value,  where  i  is  the  last  year  of  service, 
with  alpha  currently  set  to  0.5.  Truncation  value  is  assumed  to  decrease 
linearly  from  the  initial  salvage  value  to  zero  over  the  expected  lifetime 
of  the  aircraft.  Mothballing  savings  are  assumed  to  be  R1  x  100  percent 
per  year  of  the  first  year  operating  cost.  This  account  of  mothballing 
savings  will  be  in  error  (low)  for  aircraft  mothballed  beyond  the  first 
year  of  their  life;  however,  this  error  will  not  be  serious  unless  the 
increase  in  operating  cost  per  year  is  large.  An  alternative  and  exact 
method  of  accounting  for  savings  due  to  mothballing  was  considered  but  the 
added  complexity  due  to  its  implementation  was  not  considered  to  be  worth¬ 
while.  The  present  value  of  R1  is  0.90.  Under  the  present  system,  actual 
ccsts  are  used  instead  of  costs  discounted  to  present  value. 

Input  Formats 

The  input  consists  basically  of  three  types  of  data  sets:  (l) 
vehicle  tables— describe  availability,  vintage,  life,  and  cost  information 
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for  each  vehicle  type;  (2)  period  tables— deseribe  length,  money  avail¬ 
able,  and  tasks  for  each  period;  and  (3)  task  tables— describe  vehicles 
which  can  be  used  for  each  task  and  alternative  ways  of  accomplishing 
the  task  with  those  vehicles.  In  addition  to  these  tables  there  is  a 
title  card  and  a  group  of  header  cardB  which  inform  the  program  of  the 
type  of  tables  that  follows.  The  formats  for  all  of  the  cards  are  given 
in  Figs.  4-5  through  4-8  and  reference  to  these  will  be  helpful  for  the 
discussion  which  follows. 

The  title  card  sets  the  major  parameters  for  the  problem.  The 
first  field  contains  the  name  of  the  run  being  made.  ThiB  name  is  used 
as  the  identification  on  the  tapes  produced  by  the  program.  This  field 
is  stored  as  alphanumeric  characters  and  should  be  left-justified  on 
the  card  to  avoid  loading  blanks.  The  remaining  fields  on  the  card  are 
all  right-Justif J jU  in  integer  format  and  contain,  in  this  order,  the  first 
year  of  the  planning  horl.’on,  the  last  year  of  that  horizon,  the  number 
of  vehicle  tables  for  the  problem,  the  number  of  task  tables,  and  the 
number  of  period  tables. 

The  header  cards  have  only  one  alphanumeric  field.  In  this  field 
is  placed  one  of  four  words,  either  the  name  of  the  type  table  which 
follows  that  card  (vehicle,  period,  or  task)  or  the  word  ENETABLE  which 
marks  the  end  of  the  data  deck.  It  is  essential  that  each  table  have  a 
header  card  and  that  there  are  exactly  as  many  tables  of  each  type  as  was 
called  for  in  the  title  card. 

The  vehicle  tables  have  three  basic  card  types.  The  first,  the 
name  card,  has  three  fields;  an  alphanumeric  field  for  the  vehicle  name, 
and  two  integer  fields,  one  for  the  first  year  that  the  vehicle  can  (or 
did)  enter  the  fleet  and  the  other  for  the  maximum  life  of  that  vehicle 
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TITLE  CARO 


1°  1 

15  | 

-1 

25 

1 

1 

1 

1 

1 

1 

1 

1 

1 

kmelcp 

t 

1 

1 

1 

1971  | 

1 

1985  j 

7 

HEADER  CAROS 


PERIOD 


TASK 


ENDTABLE 


type.  The  second  type  of  card  is  only  for  those  vehicles  which  are 
presently  in  the  fleet,  and  they  are  used  to  describe  the  number  and  age 
of  the  vehicles  inherited  by  the  problem.  Each  card  has  eight  ten-digit 
integer  fields,  and  each  field  contains  the  number  of  vehicles  of  the 
type  described  on  the  first  card  which  were  purchased  in  some  specific 
year.  The  first  field  on  the  first  card  of  the  second  type  contains 
the  number  inherited  from  the  first  year  that  the  vehicle  entered  the 
fleet  (that  year  which  is  listed  in  field  two  of  card  type  one).  Each 
field  represents  the  years  sequentially  from  that  year  to  the  last  year 
prior  to  the  starting  year  of  the  planning  period,  so  that  if  a  vehicle 
entered  the  fleet  10  years  prior  to  the  planning  period,  it  would  require 
two  cards  to  describe  that  vehicle’s  contribution  to  the  fleet;  the  first 
would  have  all  eight  fields  filled  and  the  second  would  have  the  first 
two  fields  filled.  The  last  card  in  a  vehicle  table  is  the  cost  card, 
which  contains  five  ten-character  floating  point  fields.  The  first  ie  a 
cost  (the  initial  salvage  value)  to  be  used  with  the  salvage  and  truncation 
equations;  the  second  is  the  ten  year  operating  cost;  the  third  is  the 
research  and  development  cost;  the  fourth  is  the  retention  rate  (l-  the 
attrition  rate);  and  the  last  field  is  the  unit  cost  associated  with  the 
linear  estimate  of  the  procurement  cost.  In  general,  the  first  and  last 
fields  will  contain  the  same  number,  although  this  is  not  essential.  All 
of  the  costs  in  each  vehicle  table  should  be  scaled  by  the  same  factor, 
such  as  10^,  so  that  the  ten  year  operating  costs  fall  roughly  betwrfbn 
1  and  10  for  all  of  the  vehicles.  This  will  give  the  best  results  in 
BBCAV2  by  avoiding  numerical  roundoff  errors. 

The  period  tables  are  also  input  with  three  card  types,  exoept 
for  inherited  (past)  periods  which  use  only  the  first  card  type.  The  first 
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card  contains  three  fields;  the  first  two  are  integer  fields  which 
contain  the  first  and  last  year  of  the  period  respectively  (if  a  period 
is  only  one  year,  these  two  entries  would  be  the  same),  and  the  third 
field  is  a  floating  point  field  containing  the  procurement  cost  constraint 
level  for  that  period.  If  the  procurement  constraints  are  not  desired, 
then  an  extremely  high  number  should  be  placed  in  the  third  field  of  the 
first  card  for  the  first  period,  so  as  to  keep  the  constraints  from  being 
binding.  Of  course,  no  constraint  need  be  given  for  the  inherited  periods 
(the  periods  preceding  the  start  of  the  planning  period).  The  second 
card  contains  a  ten-character  integer  field  for  the  number  of  tasks  to 
be  done  in  that  period  and  a  ten-character  floating  point  field  for  a 
scale  factor  ( in  that  order) .  The  scale  factor  is  ip  lied  to  all  of  the 
tasks  and  can  be  thought  of  as  a  representation  to  the  growth  in  mission 
requirements  from  one  period  to  the  next.  The  third  card  type  haB  16 
five -character  fields  which  are  used  in  pairs.  The  first  field  of  each 
pair  is  an  Integer  task  identification  number,  and  the  second  field  is  an 
individual  scaling  factor  related  solely  to  that  task.  This  factor  might 
be  used  for  the  number  of  times  the  task  must  be  independently  performed 
in  that  period  or  for  other  similar  multiplicative  factors.  If  more  than 
eight  tasks  are  to  be  performed  in  a  period  then  a  second  card  type  three 
must  be  used. 

The  final  type  of  table  is  the  task  table.  Its  first  card  has 
three  ten-character  integer  fields  which  contain  the  task  identification 
number,  the  number  of  columns  in  the  table,  and  the  number  of  rows  (alter¬ 
natives)  in  that  table.  The  second  card  contains  eight  ten-character 
alphanumeric  fields  for  the  vehicle  names  associated  with  each  column. 
These  names  are  left-justified  and  are  the  same  names  as  appear  in  a 


vehicle  table.  Card  type  three  is  used  for  inputing  the  alternative  ways 
of  performing  each  task,  and  each  card  represents  a  different  alternative, 
so  that  there  are  exactly  as  many  cards  as  there  are  alternatives  given 
in  field  three  of  card  one.  Card  type  three  has  eight  ten-character 
floating  point  fields.  Each  field  contains  the  number  of  the  type  vehicle 
represented  by  that  column  which  is  used  in  accomplishing  the  task  under 
the  alternative  given  by  that  card. 

There  are  only  two  limitations  on  how  the  data  deck  can  be 
organized.  First,  a  task  table  must  not  precede  the  vehicle  table  for  any 
vehicle  referenced  ir  that  task  table,  and  second,  although  the  period 
tables  may  be  separated  by  other  tables,  they  must  be  entered  in  chronological 
order.  However,  to  avoid  any  problems,  the  structure  shown  in  Fig.  4-9 
is  recommended. 

Output  Description 

The  final  output  of  the  program  includes  a  tape  which  contains 
two  files;  the  unlabeled  matrix  file  and  the  reference  list  file.  The 
matrix  file  is  composed  of  four  parts;  a  record  containing  the  number  of 
rows  and  columns  in  the  matrix  and  the  upper  bounds  for  the  non-linear 


variables,  a  title  record,  a  row  descriptor  record,  and  the  matrix.  The 
initial  record  is  formatted  (2I6/(6F12.4) ) ,  The  title  card  is  formatted 
by  (A4,  10X,  A8),  where  the  first  four  alphanumeric  characters  contain 
the  word  "NAME"  and  the  InBt  eight  have  the  problem  title.  The  row 
descriptor  is  a  vector  which  tells  the  main  program  whether  the  row  is  the 
type  equal  (0),  less  than  or  equal  (l),  greater  than  or  equal  (2),  free 
(3),  or  generalized  upper  bound  (4).  It  is  formatted  as  (112).  The 
elements  of  the  matrix  follow  this  vector  and  have  the  format  (F12.4),  und 
are  blocked  into  records  by  column.  The  reference  list  file  has  no 


ENDTABLE* card 


ALL  TASK  TABLES  (IN  NUMERICAL  ORDER) 


ALL  VEHICLE  TABLES  (ANY  ORDER;  PREFERABLY  WITH  R&D  VEHICLES 
FIRST,  INHERITED  VEHICLES  LAST) 


TITLE  CARD 
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header  cards  and  ia  formatted  totally  by  (15,  4X,  A7),  where  the  first 
field  contains  the  column  number  and  the  last  field  the  column  name. 

The  printed  output  is  rather  lengthy,  being  composed  of  four 
major  sections.  The  first  section  is  merely  a  tracer  through  the  input 
deck,  ao  that  if  an  error  is  found  in  the  formats,  the  location  of  that 
error  ia  fairly  well  known.  The  second  section  is  a  partial  listing  of  the 
MPS36O  file  which  can  be  used  for  spot  checking  the  values  in  the  file. 

The  third,  section  is  the  cross  reference  list  for  the  column  numbers  and 
names.  At  the  head  of  this  list  is  the  row  descriptor  vector  and  at  the 
end  is  a  small  section  of  data  (number  of  rows  and  columns,  and  the  upper 
bounds  on  the  vehicles)  which  are  needed  for  input  to  BBCAV2.  The  final 
section  is  a  documentation  listing  of  all  of  the  input  data  for  the  run. 

THE  MAIN  PROGRAM 
Program  Logic 

The  method  of  solution  ia  of  course  an  implementation  of  the 
algorithm  presented  in  Chapter  3.  The  first  node,  which  represents  the 
linear  underestimate  of  the  entire  problem,  is  solved,  as  a  special  case 
of  the  general  solution  procedure  by  the  routine  B0X1.  This  routine 
establishes  a  branching  tree  (containing  only  one  node),  sets  values 
for  certain  key  parameters,  and  defines  several  arrays  necessary  for  the 
algorithm.  All  subsequent  nodes  are  solved  in  pairs  by  examining  both 
branches  from  an  existing  node  on  the  tree. 

Although  the  algorithm  guarantees  that  an  optimal  solution  can  be 
found  after  the  solution  of  a  finite  number  of  nodes,  the  program  is  not 
usually  allowed  to  run  until  thiB  has  been  proven!  There  are  several 
reasons  for  this — the  main  one  being  that  the  time,  and  hence  money,  involved 
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In  finding  this  solution  may  be  extremely  large.  Also  of  importance  when 
dealing  with  large  problems  having  many  near-optimal  solutions  is  the 
problem  that  it  may  be  impossible  to  determine  which  solution  is  indeed 
optimal  because  of  roundoff  and  other  amall  numerical  errors.  Because  of 
this  the  program  is  written  so  that  it  will  solve  for  a  solution  which  is 
only  guaranteed  to  be  within  some  tolerance  of  the  optimal  solution.  This 
tolerance  level  is  an  input  parameter  (e)  which  is  used  to  insure  that 
optimal  solution  times  1  +  c  is  greater  than  the  current  best  solution 
before  the  algorithm  terminates.  It  is  recommended  that  e  ^  .00001  be 
used  to  avoid  the  problems  of  numerical  errors. 

When  solving  any  given  subproblem,  the  program  performs  a  simple 
transformation  on  the  subproblem  before  solving  it  by  means  of  the  LP. 

This  transformation  involves  shifting  the  axes  of  the  problem  such  that 
all  of  the  lower  bounds  for  the  LP  problem  are  zero.  The  sum  of  the  costs 
of  the  non-zero  lower  bounds  are  stored  as  the  variable  EKO.  The  actual 
lower  bound  to  the  node  is  then  the  cost  of  the  LP  problem  plus  the  value 
EKO,  and  the  actual  values  of  the  x-vector  are  given  by  the  LP  x-vector 
plus  the  lower  bound  vector.  This  simple  transformation  is  used  to 
simplify  the  LP  solution  procedure  by  eliminating  the  need  to  check  lower 
bounds . 

The  program  makeB  use  of  the  "ordered  list"  concept  for  selecting 
a  node  for  branching.  However,  the  list  itself  is  not  literally  ordered 
so  that  each  time  u  node  is  sought  the  list  is  searched  to  determine  which 
node  lias  the  least  lower  bound.  This  node  is  then  removed  from  the  list 
leaving  a  gap  which  is  marked  but  not  filled.  Then  when  new  nodes  are 
created,  any  gaps  are  filled  before  making  the  list  longer.  The  procedure 
terminates  when  the  least  lower  bound  on  the  list  is  greater  than  the  beet 
solution  found  divided  by  1  +  e. 
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Because  of  Its  size,  the  matrix  of  coefficients  is  stored  on  a  disk 
file,  however  certain  parts  are  kept  in  core  at  all  times.  The  b-vector 
[BO(lOO) ]  is  kept  in  core  so  that  the  changes  in  the  right-hand-side  based 
on  changing  the  lower  bounds  of  the  master  variables  can  be  rapidly  made 
for  each  node.  The  cost  vector  [C(l0)3  for  the  non-linear  terms  is  also 
stored  in  core  since  these  elements  are  ohanged  at  eaoh  node.  Finally 
the  column  data  for  each  of  the  non-linear  variables  [T(l00,10)]  are  kept 
in  core  si  ice  they  are  used  to  update  the  B  vector. 

The  program  has  been  constructed  to  be  repetitive  in  order  to  solve 
for  off -optimal  solutions,  i.e.,  interesting  solutions  near  the  least-cost- 
solutlon.  This  means  that  any  number  of  problems  which  use  the  same  matrix 
of  coefficients  can  be  run  at  one  time.  For  example  one  cnuld  run  the 
optimal  solution  and,  after  that  is  found,  run  the  problem  for  the  best 
solution  for  which  no  resources  requiring  R&D  are  allowed.  The  technique 
for  doing  this  is  discussed  in  the  section  on  input  formats. 

Core  Allocation 

This  program  stores  the  main  array  of  information,  the  matrix  of 
coefficients,  on  high-speed  auxiliary  storage  (drac).  However  in  addition 
to  this,  the  program  has  almost  45,000  octal  words  of  common  core  storage. 
The  dimensions  of  the  arrays  in  these  carmon  areas  are  dependent  on  only 
three  parameters: 

(1)  number  of  rows  in  matrix  £  100 

(2)  number  of  nonlinear  variables  £  10 

(3)  number  of  nodes  on  branching  list  £  25 

The  total  core  storage  requirement  is  114,251  octal  words  on  the  CDC 
6400  system,  which  is  subdivided  as  follows: 


OCTAL 


DECIMAL 


CDC  system  routines 

7,312 

3,786 

COMMON  Storage 

44, 514 

18,764 

BBCAV2 

22,063 

9,266 

BOX  1 

334 

220 

GETASQ 

l4o 

96 

GETC 

202 

130 

GETPHI 

320 

208 

INITA 

375 

253 

NXBRN 

303 

195 

PAEAMS 

241 

161 

PRESET 

131 

89 

READIN 

65 

53 

SET 

15 

13 

TABOUT 

£33 

155 

TIMEC 

126 

86 

LP 

430 

280 

BOUND 

60 

48 

COLUMN 

560 

368 

DISC 

412 

266 

DOT 

70 

56 

ESCAPE 

362 

242 

EXITS 

72 

58 

FEASCH 

522 

338 

INVERT 

477 

319 

10 

666 

438 

KEYCH 

232 

154 

KEYFND 

124 

84 

MAP  IN 

564 

372 

MAPOUT 

1,135 

605 

PIVOT 

223 

147 

PRIMAL 

620 

400 

ROW 

467 

311 

SETBND 

73 

59 

SETUP 

361 

241 

STATUS 

465 

309 

XCHECK 

774 

508 

114,251 

39,081 

USER'S  SUBROUTINE 
GET  PHI 

It  is  through  this  subroutine  thnt  the  user  inputs  his  non-linear 
cost  functions.  The  routine  uses  these  functions  to  determine  the  cost  of 
specific  numbers  of  each  resource,  or  to  determine  the  total  coBt  of  a 


solution  for  a  specif io  node.  These  functions  are  defined  in  the  section 
of  the  routine  betveen  statement  150  and  statement  l4o. 

The  functional  value  (oost)  is  denoted  by  FHI(I)  for  the  Ith  resource. 
It  is  described  as  a  function  of  XFHI( I) ,  where  XFHI(I)  is  the  independent 
variable  representing  the  number  of  Ith  type  resources  purchased.  The 
examples  shown  in  the  listing  are  of  the  form: 

01  ■  Ri  +  *i 

where  is  the  R&D  cost,  0^  is  the  linear  cost  coefficient,  and 
describes  the  "learning"  rate  on  cost  as  purchase  size  Increases. 

This  routine  should  be  put  together  using  the  following  guidelines: 

(1)  The  (I.GT.7)  phrase  In  statement  150  should  have  the  7  changed 
to  be  the  number  of  non-linear  functions  (NCF)  to  be  described  In  the 
routine. 

(2)  This  should  be  followed  immediately  by  a  computed  go  to 
statement  of  the  form 

GO  TO  (101,  102,  ...,  100  +  NCF),  I 

(3)  If  the  R&D  cost  for  the  Ith  resource  Is  zero,  then  the 

section  describing  Its  cost  function  should  contain  two  cards  of  the  form 

n  FHI(I)  -  ... 

GO  TO  200 

where  n  Is  the  statement  number  such  that  n  ■  100  +  I. 

(4)  If  the  R&D  cost  is  greater  than  zero,  then  an  additional 

card  is  ne  ided  so  the  form  of  the  Lection  is 

n  IF(XFHl(  I) .LT. . .0001)  GO  TO  140 
FHI(I)  -  ... 

GO  TO  200 

where  n  has  the  same  meaning  as  above,  and  the  IF  statement  prevents  the 

inclusion  of  R&D  cost  when  the  system  is  not  needed. 
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The  program  viU  assume  that  the  resources  are  numbered  1  thru  NCF 


according  to  the  order  printed  in  the  output  from  the  matrix  generator, 
so  one  should  be  careful  to  associate  the  appropriate  function  with  the 
variable  for  which  It  was  intended. 

Input  Formats 

The  Input  deck  for  this  program  is  much  smaller  than  that  for  the 
matrix  generator.  There  are  only  four  basic  types  of  cards  used  for  this 
program.  They  are  shown  in  Figure  4-10. 

The  first  card  in  the  deck  is  the  solution  name  card.  It  contains 
a  40-character  alphanumeric  phrase  which  describes  the  solution  which  will 
be  achieved  with  this  deck.  This  phrase  is  placed  at  the  beginning  of  the 
solution  file  and  will  appear  on  the  top  of  each  page  of  output  from  the 
report  generator. 

The  second  card  is  the  Integer  parameter  card.  It  is  formatted  as 
12  fields,  each  containing  6  integer  characters.  The  first  two  fields  are 
no  longer  used  by  this  program.  The  third  field  contains  the  number  of 
variables  (columns  in  the  matrix)  for  which  coBt  sanctions  have  been 
developed  and  programmed  in  GETFHI.  These  will  be  the  first  columns  in 
the  matrix.  The  ninth  and  tenth  fields  contain  the  preset  dimensions  of 
the  array  HLIGT,  which  are  currently  set  at  25  and  131,  respectively .  The 
fourth  and  fifth  fields  are  no  longer  used  by  the  program. 

Fields  6,  7,  8  and  11  are  all  used  to  control  the  output  from  the 
program.  If  these  fields  are  set  to  zero,  the  output  they  control  will 
be  suppressed,  and  if  they  are  set  to  one,  the  output  will  be  printed. 
Field  6  prints  the  suox’outine  names  as  they  are  called;  it  is  normally 
used  for  tracing  and  debugging  and  hence  should  normally  In:  set  to  zero. 
Field  7  prints  the  primal  Iterations  of  the  linear  program,  and  l'iela 
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prints  the  entire  solution  of  the  LP,  however,  field  8  is  only  effective 
if  field  7  is  set  to  one  also.  These  two  fields  would  normally  be  set  to 
zero  unless  one  were  interested  in  closely  examining  the  properties  of 
the  linear  underestimates.  Field  11  is  the  only  output  control  normally 
used  during  production  running,  and  it  lists  the  column  numbers  and  values 
in  the  solution  at  each  node. 

The  last  field  is  a  termination  criterion  established  by  the  user. 
Specifically,  it  is  the  maximum  number  of  nodes  which  the  program  will 
evaluate  before  it  outputs  a  solution.  This  can  be  used,  for  example, 
when  one  is  evaluating  off-optimal  solutions  and  wishes  only  to  get  the 
solution  corresponding  to  the  first  linear  underestimate  of  the  problem. 

The  third  card  of  the  input  deck  is  the  real  parameter  card  and  it 
lias  1*  fields  of  12  character  floating  point  numbers.  The  first  field  is 
the  epsilon  parameter  which  was  previously  discussed.  The  second  field 
is  another  termination  criteria;  the  maximum  number  of  seconds  which  each 
solution  will  execute  before  terminating.  This  is  not  the  B&me  as  the 
time  limit  on  the  Job  card  since  this  latter  is  the  limit  on  the  sum  of 
all  solutions  combined.  The  third  field  is  the  number  of  basis  cards  in 
the  input  deck  (if  no  basis  is  input,  leave  this  field  blame) .  The  last 
field  is  another  output  control.  If  this  field  is  equal  to  zero,  it  will 
suppress  all  output  except  the  initial  problem  description  and  the  final 
solution  (if  detailed  oi  ‘•.put  was  called  for  by  previous  options,  put  1.0 
in  this  field). 

The  firu  1  group  of  cards  are  t lie  basis  cards;  those  eardc  are 
optional  and  need  not  be  included  at  nil.  liovcver,  they  can  he  used  to 
accomplish  two  important  functions.  First,  they  can  be  used  to  define  an 
Initial  basic  solution  (which  may  or  may  not  tic  feasible),  and  If  tide 


b-2h 


basic  solution  is  carefully  chosen,  it  can  greatly  reduce  the  number  of 
primal  iterations  required  to  find  an  optional  solution.  This  is 
accomplished  by  creating  one  basis  card  for  each  column  that  one  desires 
to  have  in  this  basic  solution.  The  basis  card  is  composed  of  an  8 
character  alphanumeric  field  and  a  12  character  integer  field.  For  the 
basic  solution,  one  places  the  word  "BASIC",  left -just if led,  in  the  first 
field  and  the  column  number  in  the  second  field.  However,  if  the  basic 
variable  is  basic  in  a  generalized  upper  bound  row,  then  the  word  "KEY" 
should  be  entered  in  the  first  field  instead  of  "BASIC".  If  there  is 
more  than  one  basic  variable  in  a  CUB  row,  only  one  should  be  "KEY"  and 
the  rest  "BASIC",  since  there  should  be  exactly  the  Bame  number  of  "KEY" 
variables  as  there  are  GUB  rows  in  the  matrix.  The  second  function 
performed  by  the  basis  cards  is  the  elimination  of  columns  from  the 
matrix.  This  is  done  by  placing  the  word  "NULL"  in  the  first  field  and 
the  column  number  in  the  second.  This  is  useful  in  running  off-optimal 
solutions,  since  for  example,  one  can  eliminate  a  resource  from  the  dux 
by  "nulling"  the  master  variable,  or  delay  the  development  of  a  resource 
by  one  period  by  nulling  the  appropriate  set  of  purchased  fleet  variables. 

The  input  deck  may  be  constructed  to  produce  as  many  solutions  as 
desired.  For  each  solution  one  creates  a  ueck  consisting  of  the  four  card 
types  Just  described.  These  separate  decks  are  then  put  together  in  any 
order  to  form  a  single  input  deck.  The  overall  structure  of  thiB  deck  is 
shown  in  Figure  4-11. 

Output  Description 

The  output  from  the  program  can  be  divided  into  three  basic  groups. 
The  first  is  the  information  related  to  the  branch  and  bound  algorithm, 
and  the  second  group  is  the  information  related  to  the  linear  program.  Both 
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of  thou  groups  are  repeatad  for  aaoh  node  of  the  branching  tree.  The 
last  group  is  for  debugging  purposes  and  consists  of  error  messages 
(found  in  the  appendix)  and  an  error  dump  routine. 

At  the  very  beginning  of  the  output  there  is  a  section  which  lists 
the  values  found  on  the  parameter  cards  and  the  value  of  the  bounds  on 
the  variables  with  concave  functions.  Following  this  is  the  general 
information  about  the  branching  tree  which  is  output  by  the  routine 
TABOUT.  When  called  it  outputs  UO,  the  value  of  the  best  solution  so 
far;  USP,  the  value  which  all  lower  bounds  must  exceed  before  UO  is 
considered  optimal;  and  SIGMA,  an  array  com  lsting  of  the  right-hand-side 
values  of  the  master  variable  constraints,  and  the  lower  bounds,  upper 
bounds  and  cost  function  slopes  of  the  master  variables .  The  routine  is 
called  both  before  and  after  the  LP  is  run.  When  called  before  the  LP,  it 
also  prints  the  nodes  on  the  branching  tree  which  must  still  be  considered. 
The  information  regarding  these  nodes  includes  the  cost  which  represents 
a  lower  bound  on  that  node,  the  number  of  the  variable  from  which  the 
next  branch  will  be  made,  the  value  of  that  variable  on  which  the  branching 
will  be  performed,  and  the  total  fixed  costB  (E^)  associated  with  that 
node.  In  addition  it  checks  to  see  if  a  new  "best  solution"  has  been 
found,  and  if  it  has,  then  it  outputs  that  XZERO  solution  by  column 
number  and  value. 

The  program  is  written  such  that  there  is  a  transformation  from 
the  actual  problem  to  the  linear  problem  which  sets  all  of  the  lower 
bounds  to  zero.  Thus,  after  the  LP  haB  derived  a  solution,  this  solution 
must  be  transformed  back  to  a  form  applicable  to  the  non-linear  problem. 
When  this  is  accomplished,  this  solution  is  output  by  the  main  routine, 
and  it  includes  the  actual  cost  of  the  solution  PHl(XAHT),  and  the  column 
numbers  and  their  values  for  those  columns  in  the  banls. 
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The  last  fora  of  output  frcn  the  trenching  routines  Is  a  list  of 


the  master  variables  showing  the  differences  between  the  linear  estinates 
and  the  non-linear  cost  functions,  and  how  these  were  calculated.  It  is 
the  largest  of  these  differences  upon  whioh  the  branching  will  be  done. 

Upon  entry  into  the  LP,  a  group  of  self-explanatory  problem 
dimension  Items  arc  output.  These  Include;  the  number  of  standard  rows 
in  the  matrix,  the  number  of  generalised  upper  bound  rows,  the  number  of 
loglcals  (slack  variables)  added  to  the  problem,  the  number  of  columns  in 
the  matrix,  the  maximum  number  of  oolumns  allowed  in  core  at  any  one  time, 
the  invert  frequency  or  number  of  primal  iterations  before  inverting  the 
B-matrlx,  the  maximum  time  the  LP  will  be  allowed  to  run,  and  the  maximum 
number  of  primal  iterations  which  may  be  executed  by  the  LP.  These  last 
two  parameters  are  set  internally  and  are  only  used  for  debugging  purposes. 

During  execution  of  the  LP,  the  subroutine  STATUS  prints  the  status 
of  the  solution  at  each  primal  iteration.  This  first  part  of  the  output 
consists  of  the  phase  (l  -  infeasible,  2  -  feasible),  the  number  of  the 
iteration,  a  field  called  "try"  which  contains  the  number  of  iterations 
made  with  the  current  core  columns  plus  1000  times  the  maximum  number 
before  replenishment  from  the  disc,  the  current  value  of  the  objective 
function,  the  number  of  potentially  good  columns  in  core  (NDJS),  and  the 
number  of  artificial  vectors  still  in  the  solution  (NAJ\TS).  The  second 
part  of  the  output  nay  contain  a  standard  group  of  items  of  information, 
or  it  may  contain  a  message  giving  a  special  condition  which  exists  at 
tiiat  point.  The  standard  output  contains  the  DJ  value  of  the  column 
brought  into  the  solution  (a  measure  of  the  sensitivity  of  the  objective 
function  to  that  column),  the  internal  column  number  of  the  column  selected, 
where  the  Internal  number  equals  the  actual  number  plus  the  numb<  r  of 
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logicals,  the  statue  code*  for  that  column,  the  internal  column  number 
of  the  column  leaving  the  basis,  Its  status  code,  and  finally  NSCAN,  the 
number  of  columns  in  core  plus  10000  times  the  number  of  disc  reads 
performed.  The  special  messages  which  may  be  given  in  place  of  this  output 
are  self-explanatory  and  have  the  general  form;  ....PRIMAL  ...  END  OF 
PHASE  2  ..  OPTIMAL,  where  PRIMAL  is  the  routine  sending  the  message. 

There  are  a  few  other  special  messages  which  nay  appear  in  the 
output  of  the  LP.  After  each  inversion  of  the  matrix,  a  check  on  the 
feasibility  of  the  solution  is  made.  If  sene  column  is  not  feasible,  it 
is  removed  from  the  basis  and  a  message  is  output  of  the  fora;  3NFEAi>  . . 

ROW  xx  COL  xx  VALUE  xx  BOUND  xx.  The  last  type  of  message  has  to  do 
with  degenerate  columns.  If  it  is  determined  that  a  column  selected  for 
entry  to  the  basis  will  not  change  the  solution,  then  it  is  rejected 
and  another  column  is  selected  and  the  following  message  is  output;  REJECTED 
COL  XX  ROW  xx  PIVOT  xx  RHS  xx. 

Upon  exit  from  the  LP,  MAPOUT  will  print  the  solution.  It  first 
gives  the  elements  of  the  basis  and  their  values,  and  then  outputs  the  key 
variables  in  the  GUB  rows  and  their  values.  Finally  It  mixes  and  orders 
the  basic  columns  and  key  columns  and  oufputs  the  column  numbers  and  values 
for  the  non-zero  valued  columns  of  the  matrix. 

Included  in  the  output  routines  of  the  program  is  an  error  dump 
routine  called  ESCAPE.  This  routine  outputs  the  arrays  NAME  -  the  status 
code,  BASIS  -  columns  in  the  basis,  KEY  -  key  columns  in  the  GUB  rows, 

JA  -  list  of  columns  in  core,  JAREJ  -  the  reject  state  of  the  columns  in 
core  (l  -  rejected,  0  -  otherwise),  ALPHA  -  work  space,  BETA  -  solution 
vector  of  basic  and  key  columns,  GAMMA  and  DELTA  -  work  spaces,  and  DJ  - 
the  objective  function  sent itivities  to  the  columns  In  core. 
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Program  Logic 

The  logic  structure  of  this  program  is  not  very  complex.  The  first 
part  works  almost  in  reverse  of  the  matrix  generator.  It  searches  the 
reference  list  to  determine  the  symbolic  names  of  the  columns  in  the  basis, 
and  then  decodes  these  symbolic  names  to  properly  account  for  the  value  of 
the  variable.  Most  of  the  remaining  portion  of  the  program  merely  formats 
and  prints  the  output. 

Core  Allocations 

This  program,  like  the  matrix  generator,  stores  all  of  its  data 
In  core.  As  a  result  almost  three-fourths  of  core  allocation  is  for 
coranon  storage.  Several  of  the  dimensioning  restrictions  for  the  previous 
two  programs  are  effective  here  also;  namely,  number  of  vehicles,  number 
of  period,  and  number  of  columns  in  the  matrix.  The  only  new  limitation 
1b  that  the  number  of  years  in  the  planning  horizon  be  less  than  or  equal 
to  20  (this  does  not  Include  years  from  which  vehicles  have  been  inherited). 
The  total  core  storage  allocation  is  shown  below: 


CDC  system  routines 
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3,056 

COMMON  Btoruge 

* 

51,554 
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REPGEN 
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SETUP 
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221 
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INSOLN 
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150 

YECOST 

- 
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95 

CINFO 
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199 

PINFO 

a 

1,623 

915 

VALUES 

XX 

_ 11,.. 

_ 12  ... 

TOTAL 

* 

70,765 

29,173 

User’s  Subroutine  -  YRCOST 


This  routine  is,  and  must  be,  the  same  identical  routine  as  is 
used  by  the  matrix  generator.  One  need  only  duplicate  the  routine  and 
insert  it  in  this  program. 

Input  Formats 

The  input  deck  for  this  program  can  be  constructed  directly  from 
the  input  deck  to  the  matrix  generator.  It  only  uses  a  portion  of  the 
data  but  the  formats  are  set  up  to  use  the  same  cards  as  were  used  pre¬ 
viously;  this  is  intended  to  help  avoid  errors  in  the  preparation  of 
input . 

The  first  card  is  the  title  card,  which  is  identical  to  that  for 
the  matrix  generator.  This  is  followed  by  the  vehicle  tables,  which 
are  placed  in  the  order  (numerical)  in  which  they  are  listed  on  the  output 
of  the  matrix  generator.  The  vehicle  tables  each  have  the  appropriate 
header  card  followed  by  card  1  and  card  type  three  (Fig.  4-6).  Note  that 
all  cards  of  type  2  should  be  removed  from  the  vehicle  tables.  Next  come 
the  period  tables.  These  have  header  card  and  a  card  number  1  (Fig.  4-7) . 
Only  the  cards  number  1  are  used  in  the  period  table.  Finally  the  ENDTABLE 
card  goes  at  the  end  of  the  deck,  so  that  none  of  the  task  tables  are  used. 

With  this  deck  that  has  been  extracted  from  the  matrix  generator, 
only  one  addition  needs  to  be  made  before  running.  On  the  cards  number  1 
of  the  period  tables,  one  must  add  in  columns  11  and  12  the  alphanumeric 
designator  for  the  period.  These  designators  are  determined  as  follows; 
”00"  for  the  period  which  contains  the  present  year,  "01"  for  the  period 
which  follows  and  starts  with  the  first  year  of  the  planning  horizon, 

"02"  for  the  periods  sequentially  that  follows,  "Ml"  for  the  period 

that  precedes  the  present  one,  and  "M2"  etc.  for  the  preceding  period  in 
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reverse  chronological  order.  Since  this  field  is  read  alphanumerically, 
it  is  essential  that  both  columns  be  punched  and  the  preceding  zeros  be 
included.  The  final  deck  has  the  general  configuration  shown  in  Fig.  4-12. 
Output  Description 

For  each  solution  that  has  been  developed  by  the  main  program, 
the  report  generator  will  print  four  tables.  The  first  contains  the 
cost  information  and  is  fairly  self-explanatory.  It  should  be  noted  that 
the  truncation  savings  is  printed  below  the  table,  so  the  total  cost  in 
the  table  is  the  real  cost  and  does  not  contain  this  credit.  Also, 
although  the  total  procurement  cost  is  exact,  the  value  during  each 
period  is  a  linear  estimate  to  the  nonlinear  cost  functions. 

The  other  three  tables  give  the  resources  purchased,  stored,  and 
used  during  each  period.  The  only  information  that  is  not  immediately 
available  is  the  number  of  resources  in  the  system,  but  this  is  merely 


the  sum  of  the  resources  used  plus  the  resources  stored. 


Fig.  4-12 — Deck  Structure  for  Report  Generotot 
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